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(a)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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani