Another hardware option that can help derby out a lot is placing the log file on a battery backed disk or even cheaper is to get a controller with a battery backed frontend cache. I have seen results on the latter and it basically removes the log sync I/O bottle neck for a number of commit bound applications with no change necessary to the application. The cache does not have to be that big as it just needs to caches the I/O from the log commit long enough for it to hit disk before the cache fills.
I don't get much server hardware to play with any more, but the last machine we got had it as a default configuration (it took us awhile to figure out why our numbers were so good :-) ).
/mikem
David Van Couvering wrote:
I have on my "like to do" plate the following:
- build a prototype in-memory store for Derby
- do some performance tests of this compared to running Derby with a *massive* JVM cache and Derby cache and RAMdisk for disk storage. A lot of machines put /tmp on RAM, you don't even need to purchase special software.
- See how they compare...
David
Kevin Foster wrote:
Elissa Newman wrote:
> Does Derby have a mode such that it runs in memory only? I am working on
> a project that needs the database to run in memory and not go to the
> disk at all (the amount of memory we have for our system should suffice
> for the database size we will have). I reviewed the available
> documentation and did not see a setting for something like this.
Has anyone tried Derby on a RAM Disk? Here's an example (Google search on "ramdisk"):
http://www.superspeed.com/ramdisk.html
It obviously wouldn't be a safe place to keep data in case of machine failure, but if safety isn't a requirement, then I would guess that performance would improve accordingly. Maybe not to the theoretical maximum speed possible without logging, but memory is a lot faster than a physical disk would be.
-Kevin
