use Perl

• Re: MySQL on a ramdisk (Score:1)

  by daxim (8218)

  http://www.joelonsoftware.com/items/2009/03/27.html [joelonsoftware.com]

  tl;dr desktop usage was faster, compile time was same
• SSD (Score:1)

  by mpeters (5802)

  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.
  • Re: (Score:1)

    by Wonko (9336)

    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 != RAM (Score:2)

  by ziggy (25)

  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.
• MEMORY storage engine (Score:1)

  by mickeyc (9421)

  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?
  • Re: (Score:2)

    by Ovid (2709)

    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.
• TMPFS on Linux (Score:1)

  by adhoc (9321)

  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.
• Steal from the otaku (Score:2)

  by Alias (5735)

  http://www.ramsan.com/success/ccpgames.htm [ramsan.com]

  The thing you want is called a RAMSAN, and I know this because I've read a ton of developer reports from EVE Online.

  Those guys have a MASSIVE performance sensitivity on their database, so they run this gigantic RAMSAN-backed database.

  If you can reach serious performance savings or developer time savings (and so can justify the cost) you probably want something like that.

  Of course, you may not need the size of the gear they use, but in principle you want the same thi