Introduction:
In part 1 we talked about Caching introduction and some terminologies of caching and in part 2 and part 3 we have seen some implementation of the famous replacement cache algorithms and now in this part we will see comparison between open source java caching frameworks as I am not that rich to buy commercial frameworks :D.
In this part we will talking about OSCache,Ehcache,JCS and Cache4J and we are going to concentrate on memory caching only, there will be performance comparison based on in memory caching by using JBoss caching benchmark framework and other test cases for cache.
The Task:
“Programming Mania” is a famous programming magazine from geeks to geeks every release from the magazine there a section specialized in frameworks comparison like MVC, ORM and so on, this month they decided that they are going to make a comparison about caching frameworks
And as we know the editors have programmatic background, in fact they are real programmers (not fake ones).
Head of Editors: this time we want to make our comparison article about caching frameworks, so we need to investigate the already used caching frameworks and I don’t need to remind you that the economic crisis affected us as well, so we will just care about open source frameworks.
Programmer 1: oh, okay no problem in that.
Head of Editors: excellent, oh and by the way, we will make it in two parts so try getting as much information as you can.
Programmer 1: ok, no problem.
Head of Editors: oh yea, one more thing, I am excepting you to be done by the day after tomorrow as we are going to release the article this week.
Programmer 1: !!! : (Shocked)
First few lines!
In order for programmer 1 to make the right comparison he needs to know what type of objects or what caching frameworks cache, some caching frameworks cache just normal POJOs while others cache portions of JSPs and so on, below is a list of common objects that caching frameworks cache
1-POJO Caching
2-HTTP Response Caching
3-JSP Caching
4-ORM Data Access Caching
The Checklist:
After Programmer 1 read a lot about caching he made a check list which enables him to make the comparison of the different frameworks, he will validates each item from the check list against all the caching frameworks.
The check list is as follow:
Programmer 1 decided to list the famous caching frameworks he is going to compare between so he selected the following frameworks:
· Java Caching System (JCS)
· Ehcache
· OSCache
· Cache4J
· ShiftOne
· WhirlyCache
· SwarmCache
· JBoss Cache
As soon he finished listing the frameworks he started to write the first few lines in the 1st part
Java Caching System (JCS):
JCS is a distributed caching system written in java for server-side java applications. It is intended to speed up dynamic web applications by providing a means to manage cached data of various dynamic natures. Like any caching system, the JCS is most useful for high read, low put applications.
The foundation of JCS is the Composite Cache, which is the pluggable controller for a cache region. Four types of caches can be plugged into the Composite Cache for any given region: Memory, Disk, Lateral, and Remote.
The JCS jar provides production ready implementations of each of the four types of caches. In addition to the core four, JCS also provides additional plug-ins of each type.
JCS provides a framework with no point of failure, allowing for full session failover (in clustered environments), including session data across up to 256 servers
JCS has a wick nested categorical removal, data expiration (idle time and max life) Extensible framework, fully configurable runtime parameters, and remote synchronization, remote store recovery, Non-blocking "zombie" (balking facade) pattern
"balking facade pattern , if a method is invoked on an object and that object is not in appropriate state to execute that method, have the method return without doing anything is in state or even throw an exception for example 'IllegalStateException' “
The configurations of JCS are set in a properties file named config.ccf file.
-Memory Cache:
JCS support LRU and MRU, The LRU Memory Cache is an extremely fast, highly configurable memory cache. It uses a Least Recently Used algorithm to manage the number of items that can be stored in memory. The LRU Memory Cache uses its own LRU Map implementation that is significantly faster than both the commons LRUMap implementation and the LinkedHashMap that is provided with JDK1.4 up. (At least that what JCS claims which we will show below )
-Disk Cache:
The Indexed Disk Cache is a fast, reliable, and highly configurable swap for cached data. The indexed disk cache follows the fastest pattern for disk swapping.
-Lateral Cache:
The TCP Lateral Cache provides an easy way to distribute cached data to multiple servers. It comes with a UDP discovery mechanism, so you can add nodes without having to reconfigure the entire farm. The TCP Lateral is highly configurable.
-Remote Cache:
JCS also provides an RMI based Remote Cache Server. Rather than having each node connects to every other node, you can use the remote cache server as the connection point.
JCS and Check List:
Our programmer 1 was checking JCS site and in the site they claimed that its LRU Map caching algorithm is faster than LinkedHashMap that is shipped with JDK 1.4 and up. So our newbie ran the following test against JCS (1.3) and LinkedHashMap JDK 1.4 and 1.6
The above is the PC specification that we are going to run our test on
In order to check what JCS claims we used their own test case from the JCS site (I will be using this test case for the rest of our frameworks testing)
The following configuration file was used during the test:
After using this test case for LinkedHashMap and JCS we got the following results:
Ehcache:
Ehcache is a java distributed cache for general purpose caching, J2EE and light-weight containers tuned for large size cache objects. It features memory and disk stores, replicate by copy and invalidate, listeners, a gzip caching servlet filter, Fast, Simple.
Ehcache Acts as a pluggable cache for Hibernate 2.1. with Small foot print, Minimal dependencies, fully documented and Production tested.
It is used in a lot of Java frameworks such as Alfresco, Cocoon, Hibernate, Spring, JPOX, Jofti, Acegi, Kosmos, Tudu Lists and Lutece.
One of its features is to cache domain objects that map to database entities. As the domain objects that maps to database entities is the core of any ORM system that’s why Ehcache is the default cache for HibernateWith Ehcache you can serialize both Serializable objects and Non-serializable.
Non-serializable Objects can use all parts of Ehcache except for Disk Store and replication. If an attempt is made to persist or replicate them they are discarded and a WARNING level log message emitted.
Another feature in Ehache is that admin can monitor the cache statistics, configuration changing and managing the cache through JMX service as Ehcache supports it (Which is really nice feature).
The configurations of Ehcache are set in an xml file named ehcache.xml file.
-Memory Cache:
EHCache support LRU, LFU and FIFO.
-Disk Cache:
Ehcache can store up to 100G of data to disk and access them in a fast manner.
Ehcache and Check List:
OSCache:
OSCache is a caching solution that includes a JSP tag library and set of classes to perform fine grained dynamic caching of JSP content, servlet responses or arbitrary objects. It provides both in memory and persistent on disk caches, and can allow your site to continue functioning normally even if the data source is down(for example if an error occurs like your db goes down, you can serve the cached content so people can still surf the site).
When dealing with static HTML pages. The Page response can be cached indefinitely in memory thus avoiding reprocessing of the page. OSCache do so by using the URI and query parameters to form a unique key.
This key is used to store page content. HttpResponse caching is implemented as a ServletFilter. Thus, the cache filter abstracts the API usage from the client.
By default, the Cache Filter holds the page response in 'Application' scope and refreshes the cache every one hour. These default values can be changed.
In case of dynamic pages (JSPs), OSCache provides tags that surround the static part in the page. Thus, only the static part of the page is cached.
OSCache can be configured for persistence cache. When the memory capacity is reached, objects are evicted from the memory and stored on a hard disk. Objects are evicted from memory based on the configured cache algorithm. Other caching places (like DB for example) you could also implement your own custom Persistencelistener (to persist in a any place you want)
OSCache supports distributed caching.
When an application is deployed in a cluster of application servers, the local cache is kept in sync by communication amongst all the caches in the cluster; this is achieved either by JMS or by JGroups.
Multiple caches can be created, each with their own unique configuration.
Another feature in OSCache is that admin can monitor the cache statistics; configuration changing and managing the cache through JMX service but this is only available via spring framework (while Ehcache supports this feature without the need of any other framework or so).
OSCache is also used by many projects Jofti, Spring, Hibernate.
OSCache is also used by many sites like TheServerSide, JRoller, JavaLobby
The configurations of OSCache are set in a property file named oscache.properties file.
-Memory Cache:
OSCache support LRU and FIFO, and any other custom replacement algorithm
-Disk Cache:
OSCache supports the Disk cache, when using memory anddisk since, when capacity is reached, item is removed from memory but notfrom disk. Therefore, if that item is needed again, it will be found on diskand brought back into memory. You get a behavior similar as a browsercache. However you still need to do some administrative tasks to clean the diskcache periodically since this has not been implemented in OSCache.
OSCache and Check List:
Cache4J:
Cache4j is a cache for Java objects that stores objects only in memory (suitable for Russian speaking guys only as there is not documentation in English and the JavaDoc is in Russian also :D).
It is mainly useful for caching POJO objects only.
In the wish list they stated that they want to support disk caching and distributed handling also but that was long time ago in 2006 but nothing happened.
It supports LRU, LFU, and FIFO caching algorithms. For storing objects in its cache, cache4j offers hard and soft references (best practice for caching frameworks is to use the weak reference and soft reference because if the JVM needs to garbage collect some objects to make room in memory, then the cached objects will be the first one to be removed).
Cache4j is implemented in a way that multiple application threads can access the cache simultaneously. It also provides easy to use programming APIs
-Memory Cache:
Cache4J support LRU, LFU and FIFO
Cache4J Check List:
Performance in action:
Ok now it is show time for this performance testing programmer 1 used 3 different test cases which are as follow:
1-Test Case from JCS site (applied on all caching frameworks)
2-JBoss Cache benchmark framework (which is really a very nice cache benchmark framework)
3-Test Case from Cache4J site (applied on all caching frameworks)
In the 1st and 3rd cache test case it just simple testing of retrieve and populating the cache, while in JBoss cache benchmark there are a lot of test cases shipped with the benchmark from replication to distributed and clustering testing.
All the testing here were performed on a single machine (no distributed testing were performed) and all the testing were performed in memory.
The versions of the frameworks we are going to test now are as follow:
OSCache: 2.4.1
Ehcache: 1.6.0
JCS: 1.3
Cache4j: 0.4
Configurations Used:
Cache4J:
SynchronizedCache cache = new SynchronizedCache();
cache.setCacheConfig(new CacheConfigImpl("cacheId", null, 0, 0, 0, 1000000, null, "lru", "strong"));
JBoss cache benchmark:
We can see here that there is nearly 8 million get operation invoked on the different cache frameworks and the JCS took the smallest time while OSCache took the biggest time
We see here that there is nearly 2 million put operation invoked on the different cache frameworks and cache4j took the smallest time while OSCache took the biggest time
The cache test performed here was in memory cache and there were 25 threads accessing the cache but we will not depend on this only and we will just continue with our testing
JCS Test Case:
The winner in this test in Ehcache which achieved outstanding results against all the other frameworks, this test is just adding 50,000 items to the cache and then retrieves them and measure the time take for adding and getting the items from cache
Cache4j Test Case:
---------------------------------------------------------------
java.version=1.6.0_10
java.vm.name=Java HotSpot(TM) Client VM
java.vm.version=11.0-b15
java.vm.info=mixed mode, sharing
java.vm.vendor=Sun Microsystems Inc.
os.name=Windows XP
os.version=5.1
os.arch=x86
---------------------------------------------------------------
This test can take about 5-10 minutes. Please wait ...
---------------------------------------------------------------
GetPutRemoveT GetPutRemove Get
---------------------------------------------------------------
cache4j 0.4 2250 2125 1703
oscache 2.4.1 4032 4828 1204
ehcache 1.6 1860 1109 703
jcs 1.3 2109 1672 766
---------------------------------------------------------------
As we can see the OSCache also took the biggest time while ehcache took the smallest time.
This test also performs addition and retrieving for cache items which means there is no cache miss (like the test cases in JBoss cache benchmark)
And the gold medal goes to!
Our candidate framework in this part is ehcache which achieved the best time in most of the testing, best performance for cache miss and cache hits and not only that but also provides very good features from monitoring statistics to distributed functionality.
2nd place goes to JCS and OSCache, JCS is really a great caching framework but wont serve the need of caching response and JSP portions but it will be a great choice for caching POJOs in while OSCache have nice features but unfortunately the performance is not that good that is because an exception is thrown when there is a cache miss which would affect the performance, most of the cache frameworks introduced here just return null if cache miss is encountered.
Finally in the last place comes Cache4j which did really a great job in caching but isn’t feature rich and also it is Russian documented so wont be helpful when you face a problem with it :D but it still achieved outstanding results.
Conclusion:
In this part we have seen different cache frameworks and we made a comparison for them but that’s not the end we still have more open source caching frameworks to check so stay tuned ;)
8 comments:
Very good series of articles! EhCache is certainly a gold medal candidate, but I wonder where JBoss cache would be situated on the winner stand ...
Brambo,
Thanks for your comment,am
glad you liked it , as for JBoss
i will talk about in in next part ;) so stay tuned
Thanks,
Very good article. Well job.
Indeed Ehcache is a very good product with:
- good performances
- distributed possibilities
- an OEM-friendly licence (Apache 2) that it's not the case of JBoss Cache (LGPL)
Loïc,
Thanks for your comment , and hope you will like the next part (which we will be talking about JBoss)
Ahmed you don't need a loads of money... Alachisoft's NCache Express is a free distributed cache. check it out. Its good for 2 server environments and works like a charm.
what about NCache, they work for Java too, although not solely for Java but they do have a free cache called NCache Express. must mention that too.
It's a very good cache benchmark article! It really helps in identifying what the best open source cache framework.
We have Websphere app server. It has built in Dynacache. I am wondering which one is the winner between dynacache and ehCache?
Thanks!!
Great article.. Nicely researched and written. You've helped making my choice of a caching framework much easier. Thanks
Post a Comment