On Dec 15, 2008, at 5:10 PM, Guido Neitzer wrote:
On 15.12.2008, at 15:27, Miguel Arroz wrote:Excellent email! I've been arguing for some time now that SSD is the way to go for DBs, it's good that some real evidence is showing up. Seek time kills DBs. :)There is some evidence showing up, true, but it also probably shows bad cache strategies or usage patterns resulting in bad hit rate on the cache.If a change from HD to SSD results in a 40x increase in query performance, something seems to be badly wrong with what the database does - or the usage pattern and / or the database setup is not optimal.It also might be a case where FrontBase hits some bad walls due to what it does while other databases will be not nearly as badly effected. For example lots of inserts into large tables with a couple indexes plain kills FrontBase performance (at least up to version 4.x).So, these values might be valid for FrontBase, but need a careful look where the real gain is coming from as a fast RAID (I'm not talking about XserveRAID obviously) combined with a working cache will deliver a very high performance, too. Especially when writing to the disks.
Well, there are a couple of issues unique to our data set.First, realize, that its not a perfect apples/oranges comparison, because I didn't run the SQL test on our Production XRaid, but rather on my local hard disk. (Because, well, the XRaid is busy. :-) ) If you look at the XBench stats for Random Read/Writes, you can see that the RAID does pretty well, it's 28 times faster on writes then a single HDD, so that would mean the SSD is only 4x faster instead of 93x for that stat. But still, 4x is nothing to sneeze at.
Next, we have a high write/read ratio. So we're fundamentally limited by Random/Write speed, because that has to get flushed to disk (though actually in FB, only the Tlog has to be flushed for the commit to work). A lot of the SQL is basically saving a bunch of log file messages. So that data can't be cached.
Also it was a freshly started database in all cases, so the row and disk caches probably weren't stabilized yet.
So yeah, there are a whole bunch of things that databases do to take advantage of the 80/20 rule. But remember, this is the performance of a single drive, and its kicking butt.
Pierce
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
