All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

A lot of SSDs don't perform as well as people think they should because file systems haven't caught up with them yet. They are still trying to minimize seeks so they'll do extra processing that's unnecessary on SSDs.

How big is your working copy (the majority of your database that you use at a time, with indexes, etc)? It might make more sense just to buy a ton of RAM if you can fit most of your working copy in memory.

A good current gen SSD should provide a pretty reasonable boost in performance for a database. The most interesting, and my favorite, number I got out of benchmarking my Intel X25-M is that it can pull over 4000 seeks per second on my laptop. The cheap 4 disk RAID 10 in my web server only pulls a bit over 300.

The thing slowing the DB tests down isn't just the disks. Its the ACID properties of the database. I'm sure MySQL is calling sync quite a bit. If it didn't, the OS disk caching would work nearly

SSD is a kind of flash, and doesn't perform at all like RAM. It's similar in that there's no rotational delay. Writes tend to be staggered so that each bit gets a comparable number of writes (which leads to much worse fragmentation, especially in write-heavy environments). You might get decent performance off of the SSD initially, but performance will likely degrade over time given a balanced or write-heavy workload.

You may want to look at the MEMORY storage engine for MySQL. I'm surprised you got such a huge boost. Are your tests write heavy? I assume you've already tweaked the query cache so you're not reading the same data over and over from disk?

The MEMORY storage engine does not support transactions [mysql.com], thus making it unsuitable for our tests. And I doubt tweaking our query cache on the test databases will do much good as, at the start of every test, we're flushing the data and loading a new set of fixtures.

I'm not sure which 'ramdisk' you are using or which OS, so if you're on Linux I'd suggest you have a look at TMPFS. I've had some good results running large builds with make and lots of linking.
It does require copying all the data in first, but this may not be an issue if you set the db path and issue all the sql from "create database test" onwards.