On 23/03/2013 9:12 p.m., babajaga wrote:
>> Since all workers get requests for large files, all workers
> should cache them or none should. <
>
> Not necessarily.
> Defining several AUF-dirs, storing different ranges of object sizes
> (size-classes), will keep all workers busy in a high traffic system, like
> the one, the starter of the thread is talking about. Because there is a good
> probability, that at each instant of time, requests for all size-classes of
> objects are active: All workers busy.
> During low traffic, the chance for at least 2 simultaneously active requests
> for the same size-class is low, so no disadvantage.
> Of course, it depends upon a "good" choice of the size-classes. Doing some
> statistics before, regarding the size of stored objects, will be necessary.
> The starter of the thread proposed 4 AUF-dirs, having a chance to have
> "hot-objects" duplicated to all 4 dirs. This will negatively influence the
> total hit rate, but improoving the response times, in case these duplicated
> objects are so "hot", to be served multiple times in parallel.
> In the opposite, using size-classes, this should increase hit-rate, because
> much more objects cachable.
You misunderstand the aspect Alex was talking about.
** The config posted splits the classes such that worker #1 caches
*only* 0-31KB objects, worker #2 caches *only* 32+ KB.
With traffic of all sizes spread randomly over the two any object going
through Squid has a 50% guarantee of being a MISS due simply to being
outside the class for the worker handling it. If the latency added by
cache lookups is to be worth doing at all you want the HIT ratio to be
as large as possible - so forcing a guaranteed MISS on half the traffic
is a bad idea.
Amos
Received on Sat Mar 23 2013 - 09:24:33 MDT
This archive was generated by hypermail 2.2.0 : Sat Mar 23 2013 - 12:00:05 MDT