Authorization

For one our project I needed proxy solution, and mysql-proxy is one of well-known, so it was logical first choice.
The obvious question which come in mind is what performance penalty we have using mysql-proxy, version 0.7.1.
So it is easy to test. (By the way sysbench recently was pushed to Launchpad, see lp:sysbench, and Percona is going to be active developer of this project and scripting benchmarks).
I took lp:sysbench with LUA script oltp_complex_ro, and tested for couple connections, here are results (in transactions per second, more is better)
| Threads | MySQL-5.0.77 | MySQL-proxy+MySQL-5.0.77 |
| 1 | 660.02 | 349.86 |
| 2 | 1158.66 | 477.77 |
| 4 | 1223.84 | 485.21 |
| 8 | 1224.22 | 455.69 |
| 16 | 1109.72 | 441.55 |
| 32 | 1059.23 | 419.05 |
| 64 | 909.98 | 414.30 |
| 128 | 882.46 | 406.28 |
ok, and let’s look on response time (for 1 thread).
MySQL
per-request statistics:
min: 1.31ms
avg: 1.51ms
max: 5.30ms
approx. 95 percentile: 1.56ms
Proxy+MySQL
per-request statistics:
min: 2.04ms
avg: 2.86ms
max: 6.44ms
approx. 95 percentile: 4.30ms
Well, I expected some penalty of using proxy… but 2-3x times, that’s overkill. Worth to consider if you want to run Query Analyzer with MySQL-proxy on your MySQL Enterprise setup.
There is alternative – Dormando-proxy, which I want to try also, but the problem is it crashed under sysbench load, so I was not able to get any results yet.
[Vadim - via www.mysqlperformanceblog.com]
One of the most typical reasons for performance and scalability problems I encounter is simply failing to do the math. And these are typically bad one because it often leads to implementing architectures which are not up for job they are intended to solve.
Let me start with example to make it clear. Lets say you’re doing some reports from your apache log files – how many distinct visitors hit the page and stuff like that. You picked full logs because they are great in flexibility – you can run any adhoc queries and drill down as much as you like. Initially traffic was small and young and with 10000 page views a day you few days of history the queries there instant which gave you a confidence this approach will work.
As the time passes and you get 1.000.000 events per day and looking to do reporting for up to the whole year worth of data you find things not working any more with response times for individual queries taking half an hour or more when it previously took seconds.
So what math would be in the case like this ? Say you have query like “SELECT page,count(*) cnt FROM logs GROUP BY page ORDER BY cnt DESC LIMIT 100″ to find the most visited pages as a simple example.
Before you can do the math (or say apply mathematical model) you really need to understand how things work. I like to call it having X-Ray vision. If you do not understand what is happening and you see MySQL Server (or any system really) as a black box magically providing you with results you can’t model its behavior which means you have little or no ability to predict it without running benchmarks.
apt-get install ubuntu-standardadduser myuserEDITOR=/usr/bin/nano visudo%admin ALL=(ALL) ALLgroupadd adminusermod -g admin myuserperl: warning: Setting locale failed.<br />perl: warning: Please check that your locale settings:<br />LANGUAGE = (unset),<br />LC_ALL = (unset),<br />LANG = "en_CA.UTF-8"<br />are supported and installed on your system.<br />perl: warning: Falling back to the standard locale ("C").<br />locale: Cannot set LC_CTYPE to default locale: No such file or directory<br />locale: Cannot set LC_MESSAGES to default locale: No such file or directory<br />locale: Cannot set LC_ALL to default locale: No such file or directoryapt-get install language-pack-enOriginal ActiveRecord sessions st ore is slow. It is fine for some low traffic sites, but it is too slow to use it for something larger. First of all, it is slow because ActiveRecord itself is slow. It is powerful ORM framework, but it is obviously overkill for such a simple task as a sessions management.
There are other possible solutions like cookie session store (session size is limited, no sensible data in sessions), memcached (no persistence + harder to implement high-available solutions).
That is why SqlSession store was created. It works with mysql directly with database APIs and works much faster than original AR session store. But sometimes it is still slow too because:
As a solution for mentioned problems FastSessions Rails plugin was born.
So, first of all, we removed id field from the sessions table, so we do not need to use auto-increment locks. Next step was to make lookups faster and we’ve used a following technique: instead of using (session_id) as a lookup key, we’ve started using (CRC32(session_id), session_id) – two-columns key which really helps MySQL to find sessions faster because key cardinality is higher (so, mysql is able to find a record earlier w/o checking a lots of index rows). We’ve benchmarked this approach and it shows 10-15% performance gain on large sessions tables.