5 comments
Quality Assurance & Test 
A big benefit of automated testing is that it is (much) faster than testing by hand. This makes it possible to use testing as a form of instant feedback. Ideally, the test should be able to tell you something is broken immediately after it breaks. This means the basic test cycle should probably run not much longer as a few minutes. In fact, XP considers this a best practice (the 10 minute build).
When doing a lot of testing with files and databases on a large project, things start to slow down pretty soon. There are several ways to speed things up, like mocking slow dependencies that are not under test or using a fast in-process in-memory database like HSQLDB. HSQLDB is only suitable for very simple database test scenarios. A pragmatic alternative to speed up a real database is using a RAM disk!
A RAM disk emulates a disk drive by storing data in the RAM memory. This means its much faster as an ordinary hard drive, but all data will be lost when the machine shuts down. For an automated test, a RAM disk is a nice fast alternative to test IO and place a temporary test database. For Windows, a free RAM disk driver is available here, there are better commercial drivers available. Most other OS-es have RAM drive functions built-in.
The free driver enables a single drive up to 64mb, which is usually enough for automated testing and probably won't hurt overall system performance. Of course, an automated load- and/or performance test needs more data, but then you wouldn't want to do those kind of tests on a RAM drive anyway. 🙂 When evaluating what to put on the RAM disk, also make sure that the database load scripts/contents are on it too, since this usually is read lots of times during the automated testing.
5 comments
I get the point of using a RAM disk. But to me it’s just another point showing the baddness of system like windows.
I’ve ran a few simple tests myself on OS X. Using a RAM disk makes no difference here. The reasoning behind this is simple. OS X recognizes which files are accessed a lot and memory maps those files. This works for writes and reads. Since OS X is a unix like system all I/O operations to disk are handled by the kernel and the kernel is free to decide when to actually write the memory buffers to disk.
Windows also has these sorts of optimizations, but apparantly “being smarter then your OS” still works with windows.
The memory mapping of files is just about the only reason why a proper shutdown is important, both with windows, OS X and any other modern desktop operating system.
Also I have seen someone perform these procedures on unit tests as well. Can’t remember if it was Peter or not.
***
On another note, using ram disks can have a very significant benefit!! When running tests which change disk state, performing those changes on a RAM disk allows a very simple and speedy reset procedure. Just unload the ram disk from memory and reinitilize it, all data restored to a pristine condition.
Jeroen Leenarts
Like any other optimization method, your mileage may vary. In a small test suite, the test bottleneck is typically not IO bound, and testing using ram disk usually needs some extra setup work, negating most of the performance benefits. I think you really only should start considering this when you are exceeding the ten minute build mark.
Peter Hendriks
Jeroen does have a point in that the OS should make sure that files that are frequently accessed should be cached in memory, in fact that is what every modern operating system (including Windows) does. The real bennefit a RAM drive will have is that it prevents all updates to Disk. Even when your OS uses delayed writes all changes will eventually get written to disk.
The same problem arrises with Databases, which usually guarantee Durability (aciD). This means that any committed transaction should allways be persisted to Disk. Even when you use a rollback transaction mechanism to reset the state of the database after the test, there will be IO involved to write the logfile etc. In this case I think A RAM drive could speed things up. I wouldn’t call this beeing smarter than the OS, the OS (of DBMS) has no way of knowing that you are not interested in Durability.
frankb
Frank’s remark is a good one.
Forced reads are circumvented by using a RAM disk. Might be a good reason to use RAM disks after all. 🙂
Jeroen Leenarts
The reason why a ram disk is always faster is explained very well by Frank, and I assume even on an uber OS like the Mac OS X, using a ram disk can make a difference. 😉 I did try this out for myself of course, and I did see significant performance gains. The reason I do not call any numbers is that it will probably vary dramatically, depending how much IO bound your test cycle is. In very small tests, the difference is probably none or worse, because using the ram disk reliably involves some extra setup. Resetting the ram disk does not seem more efficient to me than just deleting the files: deleting files should be even faster.
Peter Hendriks