Performance issues when using SSD for a developer notebook (WAMP/LAMP stack)?

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 Windows 7 64-bit with 4GB RAM and 128 GB SSD (Corsair P3 128).

My initial experience was what I expected, fast boot, quick load of all the applications (Eclipse now takes 5 seconds as opposed to 30 seconds 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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?

It seems like I finally found the root of the problem, apparently SSDs may suffer performance degradation when used in laptops having Intel HM55 or PM55 chipsets. Please see my own full answer below.

Solution 1:

In other words, disk-level benchmarks give outstanding results to your SSD, while when used in practice, the disk is hellishly slow. So something is slowing things down, making access to files much slower than expected.

There might be few reasons:

• The most probable: there is an antivirus. Some are really benchmark killers, and you can hardly predict how do they affect performance without testing.

• Something other makes it slow to access file. Every time you seem to test many operations on small amounts of data. But what are the performances when you read or write a 10 GB file?

• OS-related configuration might be different. For example the OS is using cache for small files one the machine with the hard drive, but not on the machine with an SSD. In this case, benchmarks are wrong for the first machine, since you're not really testing the speed of the hard disk.

• Disk-related configuration might be different. Options like those related to write-caching policy (in Windows) can affect performance.

• The SSD may not function properly.

Solution 2:

After a long week of struggling with settings for better performance, I finally found some tweaks that gave the expected results. (This is a Fujitsu LIFEBOOK S751 notebook with Intel HM65 chipset and BIOS based on Phoenix TrustedCore Notebook)

In BIOS, under Advanced / Miscellaneous settings, Hardware Power Management section, there were two configuration options for

• CPU power saving on idle state (AC)
• CPU power saving on idle state (Battery)

The first one was set to "Energy Saving", the second one for "Long Battery Life". I set both to normal, and lo and behold, I got a magnitude better reply times on all my test cases.

Apparently others have run into this issue as well: http://forum.notebookreview.com/solid-state-drives-ssds-flash-storage/513313-laptops-w-intel-series-5-chipset-can-not-take-full-advantage-fast-ssds.html

Quoting from this thread:

According to benchmarks run by several members it seems that laptops with Intel HM55 and PM55 can not take full advantage of fast SSDs. These chipsets are very common in modern notebooks. The performance hit is especially visible in 4K random read and write performance. The problems seem to be caused by an agressive implementation of power saving features...

Of course now the fan keeps spinning up at every 5 seconds or so, which is quite annoying, but at least I'm able to do my job.