Wednesday, October 6, 2010

A Couple Minutes With Ehcache BigMemory Pounder...


Introduction

UPDATE: This product was released (No longer in beta)

Ehcache with BigMemory is now out in beta. One of the challenges when confronted with a new technology is exercising and understanding it's characteristics. Sure, you can read the docs, Google for some blogs, integrate it with your application and maybe write some samples, but that's a lot of work. Plus those approaches may not give you a clear picture of the various characteristics of the software. In order to make things a bit easier I've released a configurable pounder application for Standalone Ehcache with BigMemory.


Getting Installed

Here are the steps to get started:

tar -xzvf ehcache-core-ee-2.3-distribution.tar.gz
  • Copy the Standalone Ehcache Pounder kit into the ehcache kit and unpack it
cd ehcache-core-ee-2.3
cp ../ehcache-pounder-0.0.5-SNAPSHOT-distribution.tar.gz .
tar -xzvf ehcache-pounder-0.0.5-SNAPSHOT-distribution.tar.gz

  • Copy your license file and your ehcache core jar into the pounder kit
cd ehcache-pounder-0.0.5-SNAPSHOT
cp ../lib/ehcache-core-ee-2.3.jar .
and copy terracotta-license.key to the ehcache-pounder-0.0.5-SNAPSHOT as well.


Running the Pounder

Now you are ready to go. First take a look at the start script in one of the template directories (i.e. templates/1G-BigMemory):

sh run-pounder.sh

Out of the box it looks like this:

java -verbose:gc -Xms200m -Xmx200m -XX:+UseCompressedOops -XX:MaxDirectMemorySize=64G -cp ".:./jyaml-1.3.jar:./ehcache-pounder-0.0.5-SNAPSHOT.jar:./ehcache-core-ee-2.3.jar:slf4j-api-1.5.11.jar:slf4j-jdk14-1.5.11.jar" org.sharrissf.ehcache.tools.EhcachePounder

This should work fine for most people. It uses a small heap of 200 meg (you may need to grow this for really big caches). It is fine to have a MaxDirectMemorySize that is larger than your memory size on your machine. Just don't have a maxOffHeap size in your config.yml that is greater than your available physical memory on your machine. Also, make sure you leave room for your OS and the JVM. For example. If you have 8G of physical memory you might do a 400m java heap, a 6G offheap and leave the rest for the OS to use.

The script defaults to verbose gc because it's useful to see those stats and compressed oops BECAUSE YOU SHOULD BE USING A 64 BIT JVM and this setting makes it much more efficient (closer to 32 bit object pointers when possible using much less heap).

I tend to run this script like this:

./run-pounder.sh | tee out.txt

That way all output of the test goes to both the screen and to the file out.txt

Configuring the Pounder

You configure the pounder using the config.yml file. You can learn about all the options in the README. Here is the sample config included in the kit:

storeType: OFFHEAP
threadCount: 33
entryCount: 1000000
offHeapSize: "1G"
maxOnHeapCount: 5000
batchCount: 50000
maxValueSize: 800
minValueSize: 200
hotSetPercentage: 99
rounds: 40
updatePercentage: 10
diskStorePath: /export1/dev

NOTE: The most important setting here is the offHeapSize. If you set this to a number greater than the amount of memory you have on your machine you will not be happy.

The offHeapSize + the heap size + the amount of memory your OS needs together must be less than the amount of physical available memory on the machine.


Output

When running the output will look like the following:
size:492120 time: 7434 Max batch time millis: warmup value size:796 READ: 0 WRITE: 15151 Hotset: 99

size = total size of cache
time = total time to execute batch
max batch time = either warm up for the load phase or the longest time it took to execute a batch (note that in a multi-threaded test on a cpu bound machine the batch times are going to be impacted.)
value size = size of the value in this batch
READ = number of reads in the batch
WRITE = number of writes in the batch
hotset = percentage of the time that reads are done from the on heap cache

At the end of each round you'll see something like this:

Took: 10899 final size was 995240 TPS: 91751 MAX GET TIME: 20

Took = total time the round took
final size = the total size of the cache at the end (this can be impacted by eviction and be less than what you loaded)
TPS = total TPS during the run
MAX GET TIME = The maximum amount of time it took to get an entry

An interesting design choice of this pounder is that the threads you define do BOTH reading and writing. So the writers can starve out the readers in a hotset test. I could have gone he other way and then the readers could starve out the writers giving overly generous TPS.

What's Next

The biggest gap right now is that I didn't implement a way to specify a rate. It always goes full throttle. I'll try to add that when I get some time if people think it's useful.

Please give me lots of feedback so we can improve both the pounder and Ehcache

Learn more at:

Posted by at No comments:
Subscribe to: Posts (Atom)