[jboss-cvs] CacheBenchFwk/doc ...

[Manik Surtani]

  User: msurtani
  Date: 07/03/13 12:25:15

  Modified:    doc      Documentation.txt
  Added:       doc      TODO.txt
  Log:
  Updated docs
  
  Revision  Changes    Path
  1.2       +17 -0     CacheBenchFwk/doc/Documentation.txt
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: Documentation.txt
  ===================================================================
  RCS file: /cvsroot/jboss/CacheBenchFwk/doc/Documentation.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -b -r1.1 -r1.2
  --- Documentation.txt	23 Dec 2005 07:31:05 -0000	1.1
  +++ Documentation.txt	13 Mar 2007 16:25:15 -0000	1.2
  @@ -82,3 +82,20 @@
     - The fully qualified class name of the report warpper used for the report generation purpose (Ref: Documentation on Reports)
   </report>
   </cachebench>
  +
  +Running clustered tests
  +=======================
  +
  +There is some rudimentary support for clustered tests at the moment, with some limitations:
  +
  +1.  Only master/slave type tests are supported, where one node performs all the cache puts and gets and performance is
  +measured on this master node.  The other nodes just act as dummies which participate in the cluster by acting as recipients
  +for network traffic.
  +
  +2.  Only one <testcase> element at a time is supported if using this setup.  Slaves will barf if configured to deal with
  +more than one test case.
  +
  +3.  Slaves need to be started manually on each host using the runSlave.sh script.
  +
  +4.  Master nodes have no "intelligence" to wait for a specified number of slaves.  This needs to be done manually, by
  +starting the required number of slaves before starting the master.
  
  
  
  1.1      date: 2007/03/13 16:25:15;  author: msurtani;  state: Exp;CacheBenchFwk/doc/TODO.txt
  
  Index: TODO.txt
  ===================================================================
  $Id: TODO.txt,v 1.1 2007/03/13 16:25:15 msurtani Exp $
  The following lists out the featues in their order of priority (High priority --> Low)
  
  1. Add the cache size to the report. Cache size would be measured as the number of objects in the cache initially.
  This would give a method of comparing the put and get times respective to the number of objects in the cache. The number
  of objects would be hard-coded when this feature is completed.
  
  2. Add object count in to the configuration file
  This would give the user a method of configuring the number of objects that he/she wishes to see going into the cache.
  
  3. A way to customize a complex object that coule be used as the object that goes in and out to the cache.
  This is to give the user a method of creating his/her own complex object declared in XML, which he could use to be used
  in the above load test. The user can indicate the number of attributes and type of the attributes for the field.
  Thus giving the user define the test objects apart from the default test objects we have.
  
  4. Tag the gcBetweenTestsEnabled with a object count, so that different VM parameters coule be tried out when
  benchmarking the chaching systems.
  
  5. Add a feature in the report that shows the object size in bytes.
  This would need some work.
  
  6.  Proper agent-based replicated tests where each node in the cluster is stressed.