Comparing the performance of various Jackrabbit configurations

Jackrabbit has two sorts of components that manage the storage of data:

• PersistenceManager^? for storing nodes and properties, in other words, the repository content
• FileSystem for storing metadata used by the Jackrabbit server

The Cosmo bundled distribution currently uses the DerbyPersistenceManager^? component to store content in an embedded Derby database and the LocalFileSystem^? component to store metadata directly into the filesystem. The content of binary properties (referred to in Jackrabbit as blobs) is also stored directly in the filesystem rather than in Derby.

As discussed in bugs 5009 and 5016, we'd like to research using the DerbyFileSystem^? component to store Jackrabbit metadata and blobs in Derby, to improve consistency and manageability.

I undertook a project to compare the performance of the existing configuration versus several combinations of proposed configurations. I performed a series of hammer runs, one for each configuration, and recorded the results below. Hammer was run on my Windows/cygwin laptop against Cosmo running on my PowerMac^? G5, both machines on the same LAN. Cosmo's repository was wiped and re-initialized before each run. The JVM was given the default heap size and Tomcat's HTTP connector used the default thread pool configuration.

With 10 client threads each doing 100 requests:

All tests succeeded. Derby blobs seems to degrade performance a little bit, but probably acceptably so.

With 25 client threads each doing 100 requests: