Re: Verify my Squid understanding

From: Duane Wessels <wessels@dont-contact.us>
Date: Mon, 01 Jun 1998 12:43:02 -0600

Yee Man Chan writes:

>Hi, everybody,
>
> I am going to write a simulator to study the performance of the
>removal policy implemented in Squid 1.1.20. Please correct my misunderstanding
s
>of Squid. Thanks!
>
>The environment I am interested:
>1) Only one squid is running
>2) My squid starts with a clean cache
>3) Simulated time period is less than one year, so I avoid any calls to
>storePurgeOld
>4) No memory is used as a cache between proxy and the outside world, ie
>all SwapIn, SwapOut functions are re-written to bypass the memory
>
>This is my understanding of the Squid LRU policy:
>1) Objects bigger than 4MB (configurable) will not be cached
>2) Squid tries to run the purge algorithm (storeMaintainSwapSpace) once
>per second.
>3) storeEntries are stored in a hash table. When storeMaintainSwapSpace is
>called, it only examines one of the buckets and then purges all the
>purgeable storeEntries as defined in storeCheckExpired.
>4) Only objects requested via GET method are cached
>5) Only objects whose URL does not contain "?" or "cgi-bin" are cached

#5 is configurable.

>6) If store_swap_size > store_swap_high, storeGetSwapSpace will scan (only
>count those scanned and unlocked) at most 256 entries stored in the hash
>table and then sort them according to lastref time and finally remove the 8
>entries that are least recently referenced every second (called only by
>storeMaintainSwapSpace).

>7) storeMaintainSwapSpace randomly chooses buckets to examine. Therefore
>the Squid hit rate is not perfectly constant, although it falls within an
>acceptable bound.

In most conditions, all of the replacement should be done by
storeMaintainSwapSpace(). The other function, storeGetSwapSpace() usually
does not remove any objects because store_swap_size < store_swap_high.

In other words, under most conditions, storeMaintainSwapSpace always
keeps the cache size between the high and low water marks.

Duane W.
Received on Tue Jul 29 2003 - 13:15:50 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:48 MST