should one use ehcache in favor of varnish? or the other way around? or both?
On some projects I use both. EHCache is perfect for intermediary results of any type (rescaled images, query results, transformed data) used by your servers. You have to adapt your software to use it though. Varnish is a transparant add-on layer for HTTP-level result caching. If you would use EHCache to cache HTTP end-results, it's a lot of work to get your implementation behave correctly according to the HTTP protocol cache behavior, you have to devise some invalidation/purging/debugging solution, avoid cache-rushes, and implemented in synchronous Servlet technology (e.g. Filter or Servlet) it won't scale as well as Varnish...
So, I would recommend Varnish for HTTP-result caching, and EHCache for intermediary, in-app result caching.
Related
I want to implement caching funtionality for Rest service that implemented in SpringBoot.
I found different way to implement this:
Use springs’s cache-abstraction(#cachable etc) that uses a internal in-memory caching using HashMap.
Use springs’s cache-abstraction(#cachable etc) with caching implementation like ehcache, caffeine etc.
HttpCaching where we need to set Cache-Control header and its different attribute.
HttpCaching using ETAG.
Difficult to decide which one is the best solution and why?
Are all these ways are related to each other or not?
Please help out me with this.
I need to cache different user and application data on a daily basis.
Context:
no experience with caches
working on a java web application that sends news articles to users displayed in a user-feed format
MySQL backend
Java middle tier using Hibernate and Jersey
I've checked out different cache technologies, and it seems like Memcached or Redis are the most used technologies in use cases similar to mine -- many reads and writes i.e. Facebook, Twitter, etc.
But I have to serialize objects before I cache them using the two above cache systems. It seemed like an unnecessary step to cache just a POJO, so I checked out POJO caches and stumbled upon JBOSS's Infinispan.
Does anyone have any good reasons why I shouldn't use Infinispan over Memcached or Redis over the serialization, and subsequent deserialization, overhead concern?
When Infinispan works in clustered mode, or when it has to offload data to external stores, it will have to face Serialization.
The good news is:
- you'll avoid any serialization costs unless it has to go somewhere else
- its own serialization mechanism is far more efficient than Java's standard serialization mechanism (and nicely customizable)
Memcached and Redis are "external" caching solutions, while with Infinispan you can keep the same Java instance cached. If this is a good or bad thing depends on your architecture specifics.
Although commonly you'll want to use a hybrid solution: use Infinispan for your in-JVM needs, cap its memory usage, have it offload what can't be fit locally to an external store, and it's easy to have it offload the extra stuff to either Redis, Memcached, another Infinispan cluster, or several other alternatives.
Your benefit is transparent integration with some popular frameworks (i.e. Hibernate) and that it can handle the serialization efficiently for you - if and when it's needed as it might need to happen in background.
I am currently aware of the following Caching Frameworks:
EHCache, MemCache, Redis, OSCache, DynaCache, JBoss Cache, JCS, Cache4J.
Apart from time taken for accessing the data from the cache, What are the different parameters/attributes for comparing these frameworks. And which framework should one use, and when?
Few things on broad level can be :
- Technology you are using
- API available for the chosen framework
- Each of the framework has a unique feature so depending on your application requirement you can pick one of the frameworks.
Description of few as picked from source mentioned below
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.
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 application
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 only)
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).
Redis:
Redis can be used for caching sessions and storing simple data structures for fast retrievals which when needed can be used for persistence as well.
It is mainly useful for caching POJO objects only.
Here is an interesting article for further insights :
http://javalandscape.blogspot.in/2009/03/intro-to-cachingcaching-algorithms-and.html
I've used spring cache abstraction and it works pretty well. And Springs' SimpleCacheManager is used as the cache storage.
Now it is bit difficult to test the application with caching and cache eviction, as there exists a considerable number of caching enabled methods. If any one can suggest a way to monitor the cache it'll be really helpful.
I have always used the java singleton class for my basic caching needs.
Now the project is using ehcache and without looking deeply into source code, I am not able to figure out what was wrong with the singleton pattern.
i.e What are the benefits of using the ehcahce framework except that the caching can be done by using xml configuration and annotation without writing the boilerplate code (i.e a static HashMap)
It depends on what you need from your caching mechanism. Ehcache provides a lot of cool features, which require a lot of well designed code to do it manually:
LRU, LFU and FIFO cache eviction policies
Flexible configuration
Persistence
Replication
many more ...
I would recommend you go through them at http://ehcache.org/about/features and decide do you really need something in your project.
The most important one:
The ability to overflow to disk - this is something you don't have in normal HashMap and writing something like that is far from trivial. EhCache can function as simple to configure key-value database.
Even if you don't use overflow to disk, there's a large boilerplate to write with your own implementation. If loading the whole database would be possible, that using memory database with persistence on write and restoring on startup would be the solution. But memory is limited and you have to remove the elements from memory. But which one, based on what? Also, you must assert cache elements are not too old. Older elements should be replaced. If you need to remove elements from cache, you should start from the outdated ones. But should you do it when user requests something? It will slow down the request. Or start your own thread?
With EhCache you have the library in which all those issues are addressed and tested.
Also there is a clustered closed source version of ehcache, which allows you to have a distributed cache. That might be one reason you might want to consider using ehcache.