RE: JCS Setup Questions

[Smuts, Aaron]

 

-----Original Message-----
From: Daniel Rosenbaum [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 07, 2005 4:01 PM
To: Turbine JCS Users List
Subject: Re: JCS Setup Questions


> What does it mean to have get enabled?  Does this mean that on a
> get from the cache the first thing it will do is send a message
> to the other servers asking if anyone has that object and if so
> send it across the wire?  Assuming it is this, how much time
> would the process wait for a response before giving up and going
> to the db?  If it is a short time, then could the lateral be
> configured that if a cache entry is put on A an invalidate
> message is sent to B, and if B then asks for that entry A would
> send it, rather than going to the database?  If I understand you
> correctly this is exactly what should happen.

> As a side question, wouldn't gets be slower when getting
> something not already in the cache, because of the time it must
> wait when asking the other caches if anyone else has a copy? 
> What affect would this have on performance of an app, especially
> if many gets are performed on loading a page?

Yes, this is all fairly obvious.  This is why caching is hard.  It is mostly a 
series of tradeoffs.

If you have get enabled for the lateral, then it will try to get data from 
other laterals.  The timeout is configurable.  I don't think this is a very 
good idea in many situations, since it can flood the network when an item is 
not in any cache and you have lots of servers and can slow things down if the 
hit ratios are low.  

Since get is so important, we have a remote cache that solves the problem  
There is only one remote place to try.  This is the big difference between JCS 
and the original jcache specification.  See the site docs.  The specification 
only had a lateral distribution model.  

The remote server model can only scale so far.  We can cluster them, dividing 
the gets, but eventually it will break down.  It is not meant for thousands of 
servers.  But since most of us don't have to scale that far, this is not a 
problem. . . 

Aaron

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]