Paul Carey

Struggling with a slow running test suite, I’d previously experimented with one db per test. Although superficially elegant, the fact that the dbs were pre-created meant that tests that should fail, passed, and vice versa.

Unsatisfied, I started looking for a different solution. CouchDB allows dbs to be created under a sub-dir, so creating a db named foo/bar will result in the following structure (assuming a default install)

• /usr/local/var/lib/couchdb/foo/bar.couch
• /usr/local/var/lib/couchdb/.foo/bar_design/my_design_doc.view

I mounted two RAM disks following the example in the man page for hdid (OS X).

DB_MOUNT=/usr/local/var/lib/couchdb/sd_test_rd
NUM_SECTORS=128000 # 2 * 1024 * Size in MB

RAM_DEV=`hdid -nomount ram://$NUM_SECTORS`
newfs_hfs $RAM_DEV
mkdir -p $DB_MOUNT
mount -t hfs $RAM_DEV $DB_MOUNT

A quick test with dd showed improved, if not stellar, performance. Running dd if=/dev/zero of=$DB_MOUNT/foo bs=1024 count=50000 took about 0.5s vs 3.5s against the HDD.

Unfortunately, this improvement wasn’t translated to CouchDB. Run time for my application’s test suite was virtually unchanged. I haven’t yet had the time to study why, but at a guess small frequent writes simply don’t see the same runtime improvement as large writes on a RAM disk.

I also tried a couple of alternatives, like the following, that resulted in no discernible difference.

• diskutil erasevolume HFS+ "ram disk" `hdiutil attach -nomount ram://4629672`

I haven’t given up yet though. #couchdb’s manveru has been talking about an in-memory Ruby implementation of CouchDB. The nascent JS implementations of CouchDB, coupled with something like Helma or POW could also be ideal for frequent quick runs of a test suite.

Update: Spotlight chose to rebuild its indexes after I rebooted, presumably as a result of my device / volume mangling.