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. :)
