I recently read a blog post by Amr Mostafa that benchmarked running MySQL databases in memory. I’ve been trying to figure out how to do this, and he had the answer: use the tmpfs filesystem, which runs in memory, to store your database. I’ll have to figure out just how difficult that is later, since I’m not a super DBA…or even really a DBA at all.
Amr is not a Rails developer, and the purpose of his benchmark was to simulate regular web traffic. His results seemed ambiguous, but I noticed something missing in his trial: writes to the database. His benchmark tests only used select statements, which read from the database. While this is the majority of most database usage, I think the perfomance gain during writes would tip the scales decidedly in favor of running MySQL in memory, if you can afford the RAM.
This has an added benefit to us Ruby on Rails developers: we could potentially use it to dramatically increase the speed of our Test Driven Development, especially for those of use (should be all of us) using autotest! TDD requires running tests every few minutes, or even seconds. And writing to the database in tests is a lot bigger piece of the puzzle, since the database is recreated from scratch before every test.
For a lot of us, test suites are manageable. Autotest only runs tests for changed files during normal development, occasionally running the entire test suite. This, coupled with judicious mocking, stubbing and unit testing techniques can keep most test suites under control. But larger apps use increasingly more tests, and higher-level tools like RSpec can be especially resource-intensive.
I tried to contact Mostafa about running some benchmarks for write speed, but my comment was considered spam! I did get a smaller message through, so hopefully I’ll hear back. If so, I’ll post a link to his thoughts/results. Until then, I may dabble with doing this myself, and seeing what amateurish benchmarks I can run myself.