[JBoss Cache] Document updated/added: "AS42x-JBossCache2xCompatibility"
by Manik Surtani
User development,
The document "AS42x-JBossCache2xCompatibility", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-9036#cf
Document:
--------------------------------------------------------------
This page presents the test made to check how JBossCache 2.x runs within AS4.2.x
N.B. AS4.2.x relies on JBossCache 1.4.x for clustering. The test does NOT refer to upgrading the library within AS4.2 distribution, but the newer binaries within applications deployed on 4.2.x configuration.
All the tests made passed. Following configurations were tested(web application is the application instantiating a JBossCache 2.x):
1. Web application deployed on a single server, started in clustered mode(jboss -c all). The server was the only member in the cluster.
2. Web application (non distributable) deployed the two nodes of the clustered server
3. The web applications deployed twice (different app context) on the single node of the server (started in clustered mode)
4. The web application, this time distributable, deployed on the two nodes of a clustered server.
What test does?
* in a jsp create a cache instance configured with replSync-service.xml
* store the instance in the servlet context, so that it does not get replicated if the application is marked as distributable.
* add an int to the cache, which is incremented on each new access to the page
* verify the following: the increments are propagated through the cluster correctly and there were no class loading conflicts.
This test is not intended to be exhaustive. If you are doing any additional tests or find any issues please update this wiki. For convenience, here is the web application used for the previous tests.
> Also see http://community.jboss.org/docs/DOC-10254
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCacheQA"
by Manik Surtani
User development,
The document "JBossCacheQA", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10282#cf
Document:
--------------------------------------------------------------
h2. QA Process for JBoss Cache
http://wiki.jboss.org/wiki/Wiki.jsp?page=QAPreReleaseChecklist
1. Prior to release the JBoss Cache team should open a JIRA issue in the JBoss QA project detailing what will be released, the date it is expected to be released on, and the SVN URL which will be used for the release. The JIRA will also note the name of any JBoss AS release (or AS branch head) with which the release must be compatible.
2. The JBoss Cache team will tag their project appropriately and enter a comment on the JIRA issue notifying QA that the project is now ready for the QA process.
3. QA team checks out JBoss Cache from SVN my SVN URL
4. svn co +url+ JBossCache
5. Check if the version information has been updated in /build.xml and src/org/jboss/cache/Version.java
6. Cache also requires the module docbook-support
6.1. svn co https://svn.jboss.org/repos/jbossas/trunk/docbook-support docbook-support
8. QA team then builds the cache project using the target distr
8.1. Build should be performed using *JDK 5.0* version compiler (for cache versions 1.3 and greater)
8.2. cd JBossCache
8.3. ./build.sh dist
10. QA team will run the JBossCache testsuite
10.1. Problems were encountered due to the following files /tmp/je.lck, /tmp/00000000.jdb being present
10.2. Attempt to remove these file before running the testsuite
10.3. Also delete all /tmp/JBossCache- directories created during the previous run of the cache testsuite.
10.4. ./build.sh interoptests
10.5. ./build.sh all-unittests-cc -Djava.awt.headless=true
10.6. ./build.sh reports
10.7. Examine the reports using cruisecontrol as a baseline, look for any nuances
10.8. The ./build.sh all-unittests -Djava.awt.headless=true tests should be repeated using *JDK 1.4* to ensure 1.4 compatibility.
10.9. org.jboss.cache.mgmt.NotificationTest and org.jboss.cache.mgmt.OptimisticNotificationTest requires JDK15 since it starts by setting up an MBean Server. Since it doesn't find one in the JDK, it attempts to start a JBoss MBean server (since org.jboss.mx classes are in the lib dir) which in turn pulls back deps on dom4j, possibly for MBean server configuration. *This test failure should be ignored on JDK 1.4*
12. Sanity checking
12.1. QA team will run the distro testsuite. Unzip the release zip (for example jboss-cache-dist-1.4.1.GA.zip) in dist folder. Following test needs to be done from there.
12.1.1. Under the etc directory, ./build.sh run.batch and ./build.sh run.aop.batch. You may have to modify some ant properties in build.properties.
12.1.2. The sleepycat jar is required for passage of all tests (it is not included in the dist)
12.3. Check all documentation is present and looks ok
12.4. Examine the Changelog.txt
12.5. Run through the tutorial page under Tutorial doc
12.5.1. Under both Dos and Linux
12.7. Run and validate output for examples under /examples/PojoCache/ , instructions to run these examples can be found in /examples/PojoCache//readme.txt
12.8. Run the beanshell tests
12.8.1. from the root dir execute runShellDemo
12.8.1.1. once the beanshell gui has started there 4 bsh files which can be executed, aopWithTx, aop, oodb, and plain
12.8.1.2. To execute them type: sourceRelative("plain.bsh");
12.8.1.3. See the tutorial under docs/tutorial/en/pdf/TreeCache.pdf (Section 6: Demo) for further instructions.
12.8.1.3.1. Section 7: Plain Cache, to run plain.bsh
12.8.1.3.2. Section 8: CacheAOP, to run aop.bsh
12.8.1.3.3. Section 9: CacheAOP with Transaction, to run aopWithTx.bsh
12.8.1.3.4. Section 10: CacheLoader Examples, to run oodb.bsh
12.8.1.3.5. Verify JBCACHE-680
14. QA will confirm proper integration with JBoss AS
14.1. The JIRA issue in the QA project will identify any AS release(s) (or branch(es), if the release is meant to be integrated into an unreleased AS version) with which the release must be compatible. If no such release is listed, AS integration testing is not required.
14.2. Check out and build the indicated AS release.
14.3. Replace the /build/output/jboss-xxx/server/all/lib/jboss-cache.jar with the jar from the new JBC release.
14.4. Execute the tests-clustering-all-stacks target in the testsuite
14.5. Check for regressions vs. the JBC release previously included with the release.
1. After passing the tests upload the jboss-cache-dist.zip, jboss-cache-minimal-dist.zip, jboss-cache-srcOnly.zip, bdbje-for-jbosscache files found in /dist
2. MD5 checksums should be generated as well
2.1. ftp upload.sourceforge.net/incoming
4. Release on sourceforge
4.1. login to sourceforge and go to jboss project
4.2. administer project
4.3. select jboss-cache
4.4. make a new release
4.5. release the project
6. Release the binary to the repository
6.1. Check both the jboss-cache.jar and jboss-cache-jdk50.jar into the repository
6.2. DO NOT modify the build/build-thirdparty file in any JBoss AS branch. Doing this is the responsibility of the AS developers.
6.3. Release the binary to the Maven2 repository
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBoss Cache 2.x (and 3.x) and JBoss AS 4.x"
by Manik Surtani
User development,
The document "JBoss Cache 2.x (and 3.x) and JBoss AS 4.x", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10254#cf
Document:
--------------------------------------------------------------
This page presents the test made to check how *JBoss Cache 2.x* runs within an application (*EAR* or *WAR*) in JBoss App Server 4.x.
> *NOTE* that while this has not been tested with JBoss Cache 3.x, it should work in principle.
h3. Background
* *JBoss AS 4.x* ships with *JBoss Cache 1.4.x* and relies on 1.4.x APIs for clustering HTTP and EJB3 sessions.
* Users may still want to use the new *JBoss Cache 2.x* APIs on JBoss AS 1.4.x.
* This pattern does NOT refer to upgrading the jars within the JBoss AS 4.x distribution, but including the newer binaries within applications deployed on the server.
h3. How it works
The class loader isolation for each app ensures that user code can use JBC 2.x while the app server still uses 1.4.x for its own clustering.
h3. Testing if this works for you
This page includes a test which you can deploy in a JBoss AS 4.x server running in clustered (or even non-clustered) mode.
h4. What does this test do?
* in a JSP, create a (2.x) cache instance configured with http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/core/trunk/src/main...
* store the cache instance in the servlet's application context, (so that it does not get replicated if the application is marked as distributable).
* add an int to the cache, which is incremented on each new access to the page
* verify the following: the increments are propagated through the cluster correctly and there were no class loading conflicts.
h4. Results
When we ran these tests, they all passed. Following configurations were tested.
1. The web application deployed on a single server, started in clustered mode(jboss -c all). The server was the only member in the cluster.
2. The web application (non distributable) deployed the two nodes of the clustered server
3. The web applications deployed twice (different app context) on the single node of the server (started in clustered mode)
4. The web application, this time distributable, deployed on the two nodes of a clustered server.
If you are doing any additional tests or find any issues please update this wiki. For convenience, the web application used in the tests is attached at the bottom of this page.
h3. Conclusion:
You can safely and easily use JBoss Cache 2.x in your application running in JBoss AS 4.x.
Note:Red Hat does not offer formal support for this combination of products. This combination is only supported by the JBoss Cache and
JBoss AS communities
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCacheSearchable"
by Manik Surtani
User development,
The document "JBossCacheSearchable", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10286#cf
Document:
--------------------------------------------------------------
h2. JBoss Cache Searchable Edition
h3. Designs
See http://community.jboss.org/docs/DOC-13454
h3. About this package
This is the integration package between JBoss Cache and Hibernate Search.
The goal is to add search capabilities to JBoss Cache. We achieve this by using http://www.hibernate.org/410.html to index user objects as they are added to the cache and modified. The cache is queried by passing in a valid http://lucene.apache.org/java/docs/index.html query which is then used to search through the indexes and retrieve matching objects from the cache.
h3. Usage
h4. How will I use jbosscache-searchable?
You can create an instance of a searchable-cache. People who use jbosscache-core frequently will find this quite easy as it is very similar to creating an instance of the cache.
The http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... interface is a sub-interface of Cache. Hence, it has the usual put(), get() and remove() methods on it. However, it also has the http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs....) method. This will return a http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... instance, which for example, the http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... method can be called. This will return all the results from the search in a list. You can also call an http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... method on it - which returns a http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... which is a sub-interface of the jdk's http://java.sun.com/j2se/1.3/docs/api/java/util/ListIterator.html.
h4. How to create a searchable cache and create a query, code examples: -
public class MySearchableCache {
public void letsFindAListOfJohn() {
// Start by creating a core cache.
Cache cache = new DefaultCacheFactory().createCache();
//Similar to that create a searchable cache. As parameters, you must pass in the cache instance that you have created and the classes that you wish to be searched.
SearchableCache searchable = new SearchableCacheFactory().createSearchableCache(cache, Person.class, Address.class, City.class);
//Lets say that I have 100 objects in this class and I want to search for the people with name John.
//As with Hibernate Search, create a Lucene query and a QueryParser.
QueryParser queryParser = new QueryParser("name", new StandardAnalyzer());
//"name" is the field within Person that I want to be searching through.
Query luceneQuery = queryParser.parse("John");
//"John" is the word within the name field that I want to be searching for.
CacheQuery cacheQuery = searchableCache.createQuery(luceneQuery);
// The cacheQuery object will now have all the instances of Person with name John. I can now put all of these into a List
List results = cacheQuery.list();
}
}
h3. Annotations on your classes.
For the classes that you want to be searched, you will have to annotate them with Hibernate Search annotations.
* http://www.hibernate.org/hib_docs/search/3.1.0.Beta1/api/org/hibernate/se... - The @ProvidedId is to tell HibernateSearch that the document id is NOT in the class, but will be provided separately when the object needs to be indexed. This annotation is on the class.
* http://www.hibernate.org/hib_docs/search/3.1.0.Beta1/api/org/hibernate/se... - This is so that Hibernate Search will index the class in Lucene and is annotated on the class.
* http://www.hibernate.org/hib_docs/search/3.1.0.Beta1/api/org/hibernate/se... - Hibernate Search will put all class-fields with this annotation into the index. If you don't annotate any class-fields they will not be indexed - for example you may not want to annotate a field called +massiveString+ because that will make your indexes very large. With each @Field, you must also specify that the +store+ property is set to +yes+. Otherwise the field will not be stored. For example: -
@Field (store = STORE.YES)
For more code examples http://wiki.jboss.org/wiki/_Files/JBossCacheSearchable/jbcsPresentation.pdf for the attached pdf which has slides from a presentation done on the searchable cache and how it works.
+Also see+ /Hibernate Search API
h3. Annotations on your class, code examples: -
@ProvidedId
@Indexed
public class Person {
@Field (store = STORE.YES)
private String name;
@Field (store = STORE.YES)
private Date dateOfBirth;
//You may not want to index this field because it will greatly increase the size of your indexes.
private String massiveString;
//Standard getters, setters etc follow.
}
h3. FAQs
*Q: Can I add stuff directly onto the Cache?*
A: Yes. SearchableCache registers a listener with the underlying cache, and is informed of any modification events. So regardless of whether you use SearchableCache or the underlying cache directly to add/modify/remove data, search indexes will get updated.
It is, however, suggested that you use the SearchableCache directly since it offers a single entry point into the cache system and will help reduce confusion and complexity.
*Q: What about POJO Cache and cache.attach()?*
A: Currently, POJO Cache is not supported but will be for the next release (1.1.0)
*Q: Must Fqns only contain String elements?*
Currently, this is a restriction that Fqn elements as well as keys need to be Strings. In future this may change to allow other objects.
*Q: Must keys only contain String elements?*
This is a restriction right now and the key part in the Fqn, key pairing has to be a String.
h3. Project Dependencies
* Hibernate Search 3.1.0 GA
* JBoss Cache v3.0.0.GA
* Commons logging v1.1.1
* SLF4J v1.4.2
h4. Using Maven or Ivy
* GroupId: org.jboss.cache
* ArtifactId: jbosscache-searchable
* Version: 1.0.0.GA
* Repository: http://repository.jboss.org/maven2
h3. Links
* Download: http://community.jboss.org/docs/DOC-12844
* API docs: http://community.jboss.org/docs/DOC-12843
* SVN: http://anonsvn.jboss.org/repos/jbosscache/searchable/
* JIRA: http://jira.jboss.com/jira/browse/JBCACHE (use the *SearchableCache* component)
* Forums: http://www.jboss.com/index.html?module=bb&op=viewforum&f=286
--------------------------------------------------------------
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"
by Kabir Khan
User development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/527633#527633
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I tried a few different things, none of which really made a difference, so I have stuck with more or less what we had, but making sure we access the (un)installCallbacks in a thread safe way:
===================================================================
--- dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (revision 101181)
+++ dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (working copy)
@@ -23,6 +23,7 @@
import java.util.Collection;
import java.util.Collections;
+import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
import java.util.LinkedHashSet;
@@ -107,8 +108,8 @@
private final Set<AbstractController> childControllers = new CopyOnWriteArraySet<AbstractController>();
/** The callback items */
- private final Map<Object, Set<CallbackItem<?>>> installCallbacks = new ConcurrentHashMap<Object, Set<CallbackItem<?>>>();
- private final Map<Object, Set<CallbackItem<?>>> uninstallCallbacks = new ConcurrentHashMap<Object, Set<CallbackItem<?>>>();
+ private final Map<Object, Set<CallbackItem<?>>> installCallbacks = new HashMap<Object, Set<CallbackItem<?>>>();
+ private final Map<Object, Set<CallbackItem<?>>> uninstallCallbacks = new HashMap<Object, Set<CallbackItem<?>>>();
/** Whether an on demand context has been enabled */
private boolean onDemandEnabled = true;
@@ -1831,14 +1832,20 @@
* @param isInstallPhase install or uninstall phase
* @return all matching registered callbacks or empty set if no such item
*/
- protected Set<CallbackItem<?>> getCallbacks(Object name, boolean isInstallPhase)
+ protected Set<CallbackItem<?>> getCallbacks(Set<CallbackItem<?>> result, Object name, boolean isInstallPhase)
{
lockRead();
try
{
Map<Object, Set<CallbackItem<?>>> map = (isInstallPhase ? installCallbacks : uninstallCallbacks);
Set<CallbackItem<?>> callbacks = map.get(name);
- return callbacks != null ? callbacks : Collections.<CallbackItem<?>>emptySet();
+ if (callbacks != null)
+ {
+ if (result == null)
+ result = new HashSet<CallbackItem<?>>();
+ result.addAll(callbacks);
+ }
+ return result;
}
finally
{
@@ -1910,20 +1917,16 @@
if (dependencyInfo != null && dependencyInfo.isAutowireCandidate())
{
// match callbacks by name
- existingCallbacks = new HashSet<CallbackItem<?>>();
- existingCallbacks.addAll(getCallbacks(context.getName(), isInstallPhase));
+ existingCallbacks = getCallbacks(existingCallbacks, context.getName(), isInstallPhase);
// match by classes
Collection<Class<?>> classes = getExposedClasses(context);
if (classes != null && classes.isEmpty() == false)
{
for (Class<?> clazz : classes)
{
- existingCallbacks.addAll(getCallbacks(clazz, isInstallPhase));
+ existingCallbacks = getCallbacks(existingCallbacks, clazz, isInstallPhase);
}
}
-
- if (existingCallbacks.isEmpty())
- existingCallbacks = null;
}
if (installs != null || uninstalls != null || existingCallbacks != null)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527633#527633
16 years, 2 months
[JBoss Cache] Document updated/added: "WritingUnitTestsForJBossCache "
by Manik Surtani
User development,
The document "WritingUnitTestsForJBossCache ", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-13315#cf
Document:
--------------------------------------------------------------
> *NOTE* See http://community.jboss.org/docs/DOC-13470for a guide to writing unit tests for http://www.infinispan.org. http://www.jboss.org/files/jbosslabs/design/infinispan/logo/images/infini...
JBossCache now runs the unit test suite in parallel. The benefit of this is reduction of execution suite execution time from 2 hours + down to about 6-7 mins (10 threads).
Threads are constraints and best practices that need to be followed in order to ensure correctness and keep the execution time to a min. This page describe all the practices needed for adding new tests, or maintaining existing ones.
1. Each test class *MUST* have an unique test name. The testing framework is configured to run all test having the same name in the same thread. This ensures that all the methods of the class are being runned sequentially, by same thread. No synchronization on test state (fixture) is needed. As a connvention, the name of the test should be: for test class org.jboss.cache.mypackage.MyTest the name is be "mypackage.MyTest". This is guarantees uniqueness.
2. For test using replicated caches, it is *mandatory* to use one of the +UnitTestCacheFactory.createCache+ methods.This will mangle the underlaying jgroups configuration, making sure that the caches you create do not interfere with caches created by different threads. Also, the +Configuration+ object passed to +UnitTestCacheFactory.createCache+ *must* be obtained through +UnitTestConfigurationFactory.createConfiguration+. Warning: do not instantiate +Configuration only+ objects directly unless absolutely necesarelly (like for testing the Configuration object itself).
3. Increase test performance. This is in order to have a short running suite. The main performance fault when writing unit tests comes from frequent instantiation of caches, especially for large clusters. A way too reduced the number of caches insances is through usage of @BeforeClass annotation, rather than the classic JUnit-like @BeforeMethod: the caches are being created only once for test class, rather than before each test method. Of course, between test methods you'll have to take care of cleaning up cache content, so that new test can run on a pristine cache. There are two utility classes you can use: +AbstractSingleCacheTest+ and +AbstractMultipleCachesTest+. These tests might be extended to support single cluster creation for all tests, also taking care of cache cleanup between test methods.
4. *DON'T* rely on Thread.sleep(). When running in heavily threaded environemnts this will most often not work. E.g. if ASYNC_REPL, don't do a sleep(someValue) and expect the data will be replicated to anoter cache instance after that. For this, you should rather use +ReplicationListener+s (check javadoc). Generally speaking, if you expect something will happen and you don't have a gurantee when, a good approach is to try that expectation in a loop, several times, with an generous (5-10secs) timeout. E.g. while (Systet.currentTimeMillis() - startTime < timeout)
{
if (conditionMeet()) break;
Thread.sleep(50);
}
5. Even though we've tried to reduce them to a min, intermittent failures might still appear from time to time. If you see such failures *in existing code* please report them jboss dev mailing list.
+
+
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "CacheBenchmarkFramework"
by Manik Surtani
User development,
The document "CacheBenchmarkFramework", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-9241#cf
Document:
--------------------------------------------------------------
h2. > NOTE: This page and this project is deprecated. It has been moved to a standalone project on SourceForge - http://cachebenchfwk.sourceforge.net - and has been heavily modernized since moving. Please refer to the project on Sourceforge for best results.
>
> This page is still retained for historic purposes.
h2.
h2. What is the Cache Benchmark Framework?
It is a framework that allows running multiple performance tests against various cache products. It was primarily conceived as a tool to benchmark different releases of JBoss Cache.
Here are some useful features offered by the framework:
* Works on any caching product - simply write a CacheWrapper implementation, which delegates calls like put(), get() and remove().
* pluggable tests - JUnit-like tests can be written to mimic your data access patterns and cache usage scenarios, making benchmarks relevant and useful. We ship with a few typical tests, such as SessionSimulatorTest which mimics storing and replicating of HTTP sessions.
* pluggable reports - prefer excel spreadsheets to CSV? Or SVG images to PNGs? Write your own report generators. Ships with a basic CSV generator.
* cluster barriers - guarantee that all running nodes synchronize during each stage of the test, such as warm-up, test and report generation phases, guaranteeing that each of these phases happens at the same time on each cluster node.
* centralized reports - each node of the cluster produces its own performance report. The primary node (first node in the cluster) then collates these reports into a single report file.
* cache warmup - triggers a sequence of operations on the cache before running any tests, to allow for hotspot compilers to optimize.
* replication assertion - asserts that any values intended to be replicated have in fact been replicated.
h2. Usage
h3. Download and install
h4. Prerequisites:
* Apache ANT version 1.7.x or higher is needed for building the binaries.
* A Java 5 JDK is needed to build and run the binaries.
* The framework ships with a number of shell scripts to enable proper classpath setting and command execution.
* Cygwin can be used for running the test on windows; if so add the scripts from to . Those scripts make an automatic conversion from unix CLASSPATH to win CLASSPATH, needed when executing
* Running cluster-wide tests require SSH and passphrase-less public keys set up on all servers, to enable cluster-wide execution.
h4. Download
There is no public release of the framework at the moment. However, it can be built from sources. The Subversion repository is .
After getting the sources from Subversion,
1. Download the JARs for specific cache products; for details pertaining to specific cache products.
2. Build the sources using in the source root directory.
h3. Configure and run a test
h4. Configuring
1. Before running a test configure . The configuration settings are documented within the file. *IMPORTANT* please read this file carefully as it contains important information, like where reports will be generated, etc.
2. Configure logging by editing . Recommended verbosity levels are WARN or ERROR, so that benchmark measurements won't be affected by unnecessary logging. In order to have individual log files for each node in the cluster, use rather than log4j's . This extends (i.e. support its configurations) and prepend the node index on the node's log file name.
3. Edit and ensure that the , and variables accurately describe the test configs you intend to run. The framework will execute each config against each existing product, on all specified cluster sizes.
4. Edit so it accurately points to the network interface to bind clustered caches to. It is a good idea for this to point to an environment variable that is set individually by each host.
h4. Running tests
* some cache products, such as Terracotta, might need additional setup, such as starting of a master servers. All this information is described in an Readme.txt file in the directory which coresponds to the benchmark product, e.g. cache-products/terracotta-2.5.0/Readme.txt. Make sure you follow any steps described in that file before running the tests.
* will kick a test run, according to the configuration you set when editing it.
* will kill all instances running all all nodes. If you are not sure whether the benchmark exit gracefully at the previous run, better run this first to make sure that there are no daemon nodes interfering with new ones.
h4. Results
Results will appear a format and in the location specified in . By default this is a CSV file, in the project root directory.
h3. Local mode
The framework can now deal with non-clustered tests as well. Use the script instead of the script which remotely runs . Note that you should use an appropriately tuned configuration for your cache, so that it does not create unnecessary network resources. Also, you should NOT use the when running tests in local mode - you won't get any results!!
This is very useful for benchmarking non-clustered performance.
h2. Write your own tests
* Every newly created test should implement . For more details please refer to 's javadoc. The framework ships with some tests already, see the package for details and examples.
* Archive your new test as a JAR file and drop it in the directory so that it is picked up by the framework.
* Specify your new test to be run in , within a element. Refer to how existing tests are specified for examples.
h2. Benchmark a new cache product
To add to the cache benchmark framework, follow these steps:
1. Create a directory
2. Create for the cache product distribution jars.
3. Create and write a cache wrapper for the product. See for example.
4. Copy to , and modify the file as per the comments to suit your product. This script builds necessary classpaths.
5. Your cache product is now ready to be benchmarked, as per the instructions above.
h2. TODOs
See http://anonsvn.jboss.org/repos/jbosscache/benchmarks/benchmark-fwk/trunk/...
h2. Feedback
Please provide all feedback on this on the http://www.jboss.com/index.html?module=bb&op=viewforum&f=157 for now, until a separate mailing list can be set up.
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "RunningPerformanceTestsOnJBossCache"
by Manik Surtani
User development,
The document "RunningPerformanceTestsOnJBossCache", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-11941#cf
Document:
--------------------------------------------------------------
h2. Running performance tests on JBossCache
1. Check out the JBossCache CVS module from HEAD.
2. Edit tests/perf/org/jboss/cache/benchmark/support/BaseTest.java - there are some properties here that need to be configured according to how many threads and loops you want to use to exercise the tests.
// This parameter specifies how many threads concurrently exercise the tests.
protected static int NUM_THREADS = 10;
// This parameter specifies the number of loops each thread runs.
protected static int NUM_LOOPS = 10000;
// wait time (in ms) between each iteration
protected static long WAIT_TIME = 100;
3. Change log levels in etc/log4j.xml to ERROR or FATAL to reduce log messages which may slow tests down.
4. Build JBossCache, run the tests and generate a JUnit report Note that you no longer need X-Windows to run performance tests
$ ant-dist/bin/ant clean jar jrunit reports
5. The JRunit target should have created a file in output/jrunit-serialized-data.dat
6. Copy this file to your local machine, and run:
$ java -cp $CLASSPATH org.jboss.jrunit.OfflineProcessor /path/to/jrunit-serialized-data.dat org.jboss.jrunit.controller.reporters.XrefReporter /path/to/output/directory
Note that you need the following jars in your classpath to run this:
* jcommon-1.0.0-rc1.jar
* jfreechart-1.0.0-rc1.jar
* jrunit.jar
7. The resulting report will have measured times in millis to run 100 operations, calculated on average based on the number of threads and loops configured in step 2 above.
h2. Writing more tests
1. Simply write your test to extend Read50PercentTest, Read75PercentTest and Read90PercentTest in org.jboss.cache.benchmark.support
2. Your test would need to override static methods staticSetUp() and staticTearDown() which is called by the framework, used to initialise and clean up resources.
3. You would also need to override doPut() and doGet() to perform gets and puts on your cache.
4. Static variables STATIC_SETUP_METHOD and STATIC_TEARDOWN_METHOD should be set (in a static block) to the Method objects representing your staticSetUp() and staticTearDown() methods respectively.
5. overriding doSingleNode and doMultiNode properties allows you to specify whether or not to run cache tests on the same TreeCache node, and on multiple TreeCache nodes.
6. Finally, set the 'configuration' property to the name of your new configuration to test.
See some of the tests in org.jboss.cache.benchmark.tests for pointers.
--------------------------------------------------------------
16 years, 2 months
