+972 52-548-6969
Getting 600 times better performance
time to read 1 min | 73 words
During the design process for the next release of RavenDB, we set ourselves a pretty crazy goal. We wanted to get a tenfold performance improvement across the board…
This is how my article about gaining 600x performance improvement the the new DZone Guide - Performance: Optimization & Monitoring starts. For the rest, head there and read it all 
.
Comments
I do not understand the sentence: "it takes 8 milliseconds to write 2 MB and flush it, but it takes 375 milliseconds to write 64 MB and flush it to SSD"
Why is the rate of 64MB slower than 2MB?
Carsten, I'm not following. The time to write a single 2MB is 8 ms. The time to write a single 64 MB is 375 ms. The issue is that you are now writing a lot more, and likely exceeding buffer sizes.
This is quite a feat for any team and any product. What I like the most about this is all the "engineering" you've put into it, to make it happen. This is again proof that the highest levels of programming are an engineering form and not craftsmanship, and in order to push the limits and improve one must apply engineering principles in programming, not just dogmatic statements like "buy more RAM" or "the hardware will catch up, don't bother" or "X will optimize the runtime under you". Again, congratulations, an impressive achievement.
I agree with Carsten. If writting 64Mb at once and flush is slower than writing 2 Mb and flush 32 times, what is the point of merging transactions?. I believe the numbers are wrong.
Jesus, No, a single 2MB write is 8 ms, on its own, when doing sequential writes. But when you start measuring across multiple calls, it grows higher. In other words a single 64MB + fsync is still faster than 32 2MB writes + 32 fsyncs.
Comment preview