Thanks a bunch for the insight.
On Oct 9, 10:26 am, John Reilly <[email protected]> wrote: > Hi, > It doesn't have to be one or the other. Sometimes it makes sense to use > both memcached and an in-process cache. The in-process cache will be > faster, but you then have to think about memory usage and cache consistency. > If you have some keys which are fetched more frequently than most, it may > make sense to try fetching from the in-process cache first and then from > memcached. > Personally I've used ehcache (with cache distribution via RMI) and > memcached, and the combination worked well for me - whether I used ehcache, > memcache or both together really depended on the use case. This is a > off-topic for this list, but regarding ehcache, I've tried using JGroups > distribution with ehcache, but ran into problems with it, but RMI with > multicast cache peer discovery is mature. The RMI distribution gets > expensive if you have a large number of boxes though since each cache has to > talk to all its peer caches. > > Hope that helps. > > Cheers, > John > > On Fri, Oct 9, 2009 at 7:24 AM, samr <[email protected]> wrote: > > > Basically when a user requests for an artifact, the backend makes > > several webservice calls to build the response. > > A few responses from these webservice calls will not change over a > > period and would like to cache this in case > > customer comes back again with the same request. > > > On Oct 9, 2:05 am, Dustin <[email protected]> wrote: > > > On Oct 8, 11:30 pm, samr <[email protected]> wrote: > > > > > memcached is in C and hence would be faster. > > > > C doesn't necessarily mean faster. Many of them have at least an in- > > > process offering which will probably perform like a java.util.Map with > > > a mutex (with maybe a bit more overhead) when running in a single-node > > > configuration. > > > > That is to say, not running a C program will be faster than running > > > a C program. > > > > My java client (http://code.google.com/p/spymemcached/) offers a > > > java.util.Map interface to memcached which will give you an easy kv > > > store while allowing you to scale your memory independently of your > > > JVMs. (though, I tend to write more to the memcached interface and > > > not the Map interface). > > > > There are trade-offs. > > > > > On feature wise the java solutions seem to be offering a lot. > > > > A piece of software with a long list of features means that the > > > features that you care about make up a smaller percentage of the > > > product. That doesn't necessarily speak to quality, but it at the > > > very least makes me care less about choosing a product based on > > > features going too far beyond my own requirements. > > > > > Please suggest what should be considered in choosing the right option. > > > > Based on the requirements you've stated, I'd suggest stating more > > > requirements. :)
