[jbosscache-dev] Cache benchmarking framework

Manik Surtani manik at jboss.org
Tue May 15 13:13:44 EDT 2007


True, but the fwk doesn't need to know about this.  All that needs to  
happen is that you create 2 cache "products" to be the same, e.g.,  
JBossCache 2.0.0, each one configured differently with different  
eviction settings.  This even applies to different lock strategies,  
replication modes, etc.


On 15 May 2007, at 15:27, Mircea Markus wrote:

> Hi,
>
> Another thing that might be interested to test is the best eviction  
> algorithm to be used in a certain scenario.
> Given a context(client), an eviction algorithm is 'better' than  
> another one if it manages to return more cached elements, as client  
> ask for them.
> (any other definitions of 'better' when it comes to eviction  
> policies?)
> As the benchmark supports multiple configs, it might be useful in  
> helping clients to fine tune their eviction policies.
>
> Cheers,
> Mircea
>
> On 3/13/07, Manik Surtani <manik at jboss.org> wrote: One of the  
> things I want o do before releasing 2.0.0.BETA2 is to get
> some idea of performance, with respect to earlier versions of JBoss
> Cache.  As such, I dug up something I started a couple of years ago,
> the CacheBenchFwk, and tidied a few things up.
>
> If you are interested in this, have a look at:
>
>         http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss/ 
> CacheBenchFwk/
>
> If you have commit rights on JBoss Cache then you'd probably have the
> same on this as well.
>
> In a nutshell, here's what the framework does:
>
> * Supports multiple cache products/versions/configs
> * Allows you to write your own test cases
> * Comes with some standard test cases
> * Produces simple CSV reports which you can import into your
> favourite spreadsheet software and generate graphs
>
> Here are some of the things I added today:
>
> * Basic replicated cache support (see docs/Documentation.txt for
> details)
>
> Some of the things I'd like to add:
>
> * Automated agent-based testing where each node in the cluster is
> stressed equally and data is measured on all nodes
> * Add throughput to the TestResult class
> * Automate the process of starting remote instances based on
> configuration settings
>
> Have a look, let me know your thoughts.  I'm sure there are many
> areas for improvement, in terms of how the tests are run, reports
> generated, etc.  As we start testing on bigger and bigger clusters,
> such frameworks could be very useful.
>
> Cheers,
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani





More information about the jbosscache-dev mailing list