On Wednesday 12 March 2008 23:32, david@lang.hm wrote:
My test ran 25 times faster because it was write intensive and included
sync. It did not however include seeks, which can cause an even bigger
performance gap.
The truth is, my system has _more_ cache available for file buffering
than I used for the ramdisk, and almost every file operation I do
(typically dozens of tree diffs, hundreds of compiles per day) goes
_way_ faster on the ram disk. Really, really a lot faster. Because
frankly, Linux is not very good at using its file cache these days.
Somebody ought to fix that. (I am busy fixing other things.)
In other, _real world_ NFS file serving tests, we have seen 20 - 200
times speedup in serving snapshotted volumes via NFS, using ddsnap
for snapshots and replication. While it is true that ddsnap will
eventually be optimized to improved performance on spinning media,
I seriously doubt it will ever get closer than a factor of 20 or so,
with a typical read/write mix.
But that is just the pragmatic reality of machines everybody has these
days, let us not get too wrapped up in that. Think about the Violin
box. How are you going to put 504 gigabytes of data in buffer cache?
Tell me how a transaction processing system is going to run with
latency measured in microseconds, backed by hard disk, ever?
Really guys, ramdisks are fast. Admit it, they are really really fast.
So I provide a way to make them persistent also. For free, I might
add.
Why am I reminded of old arguments like "if men were meant to fly, God
would have given them wings"? Please just give me your microsecond
scale transaction processing solution and I will be impressed and
grateful. Until then... here is mine. Service with a smile.
Daniel
--
