Performance issues when using SSD for a developer notebook (WAMP/LAMP stack)?
- by András Szepesházi
I'm a web application developer using my notebook as a standalone development environment (WAMP stack). I just switched from a Core2-duo Vista 32 bit notebook with 2Gb RAM and SATA HDD, to an i5-2520M Win7 64 bit with 4Gb RAM and 128 GB SDD (Corsair P3 128).
My initial experience was what I expected, fast boot, quick load of all the applications (Eclipse takes now 5 seconds as opposed to 30s on my old notebook), overall great experience. Then I started to build up my development stack, both as LAMP (using VirtualBox with a debian guest) and WAMP (windows native apache + mysql + php). I wanted to compare those two.
This still all worked great out, then I started to pull in my projects to these stacks. And here came the nasty surprise, one of those projects produced a lot worse response times than on my old notebook (that was true for both the VirtualBox and WAMP stack). Apache, php and mysql configurations were practically identical in all environments. I started to do a lot of benchmarking and profiling, and here is what I've found:
All general benchmarks (Performance Test 7.0, HDTune Pro, wPrime2 and some more) gave a big advantage to the new notebook. Nothing surprising here. Disc specific tests showed that read/write operations peaked around 380M/160M for the SSD, and all the different sized block operations also performed very well.
Started apache performance benchmarking with Apache Benchmark for a small static html file (10 concurrent threads, 500 iterations).
Old notebook: min 47ms, median 111ms, max 156ms
New WAMP stack: min 71ms, median 135ms, max 296ms
New LAMP stack (in VirtualBox): min 6ms, median 46ms, max 175ms
Right here I don't get why the native WAMP stack performed so bad, but at least the LAMP environment brought the expected speed.
Apache performance measurement for non-cached php content. The php runs a loop of 1000 and generates sha1(uniqid()) inisde. Again, 10 concurrent threads, 500 iterations were used for the benchmark.
Old notebook: min 0ms, median 39ms, max 218ms
New WAMP stack: min 20ms, median 61ms, max 186ms
New LAMP stack (in VirtualBox): min 124ms, median 704ms, max 2463ms
What the hell? The new LAMP performed miserably, and even the new native WAMP was outperformed by the old notebook.
php + mysql test. The test consists of connecting to a database and reading a single record form a table using INNER JOIN on 3 more (indexed) tables, repeated 100 times within a loop. Databases were identical. 10 concurrent threads, 100 iterations were used for the benchmark.
Old notebook: min 1201ms, median 1734ms, max 3728ms
New WAMP stack: min 367ms, median 675ms, max 1893ms
New LAMP stack (in VirtualBox): min 1410ms, median 3659ms, max 5045ms
And the same test with concurrency set to 1 (instead of 10):
Old notebook: min 1201ms, median 1261ms, max 1357ms
New WAMP stack: min 399ms, median 483ms, max 539ms
New LAMP stack (in VirtualBox): min 285ms, median 348ms, max 444ms
Strictly for my purposes, as I'm using a self contained development environment (= low concurrency) I could be satisfied with the second test's result. Though I have no idea why the VirtualBox environment performed so bad with higher concurrency.
Finally I performed a test of including many php files. The application that I mentioned at the beginning, the one that was performing so bad, has a heavy bootstrap, loads hundreds of small library and configuration files while initializing. So this test does nothing else just includes about 100 files. Concurrency set to 1, 100 iterations:
Old notebook: min 140ms, median 168ms, max 406ms
New WAMP stack: min 434ms, median 488ms, max 604ms
New LAMP stack (in VirtualBox): min 413ms, median 1040ms, max 1921ms
Even if I consider that VirtualBox reached those files via shared folders, and that slows things down a bit, I still don't see how could the old notebook outperform so heavily both new configurations. And I think this is the real root of the slow performance, as the application uses even more includes, and the whole bootstrap will occur several times within a page request (for each ajax call, for example).
To sum it up, here I am with a brand new high-performance notebook that loads the same page in 20 seconds, that my old notebook can do in 5-7 seconds. Needless to say, I'm not a very happy person right now.
Why do you think I experience these poor performance values?
What are my options to remedy this situation?