Re: [squid-users] Caching in forward proxy mode

On Tue, Apr 24, 2012 at 5:37 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 24/04/2012 10:32 p.m., Ahmed Talha Khan wrote:
>>
>> Hey All,
>>
>> Does squid cache web-pages when configured in the forward interception
>> proxy mode i.e http_port x:y intercept.? If so how can it be turned
>> off.?
>
>
> "cache deny all" does what you ask.
>
>
>>
>> I actually want to bench-mark squid performance in terms of
>> requests-per-second that squid can support.
>
>
> Disabling caching will not tell you that. It will tell you the average speed
> of Squid under DoS or worst-case traffic conditions. ie the minimum
> capacity.

In a way, i am actually interested in the capacity of squid. I do not
want to include the cache functionality of the proxy. Not including
the cache will mean what numbers squid can support when all requests
are distinct, when the request/response are all new i.e no CACHE_HIT.
So every time squid has to go to the origin and pull the full body
data.

Servicing data of the cache is a big advantage of squid. But we need
to see the performance of squid without cache if we need to see the
data-path latency(or lower requests/sec) introduced by squid. Cache
add a negative time factor to improve the latency.

Comments...

-talha

>
>>  I do not want squid to
>> cache the web pages on which i am doing the test. The reason is
>> obvious that  i do not want squid to service that page from its
>> cache.:). I want it to get the pages from the server every time. I am
>> using AB(apache-benchmark) to do a comparison between request process
>> times when squid is inline vs when squid is not there. Looking at the
>> access.log file gives this for my test page.
>>
>> 1335266704.412      0 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>> 1335266704.415      0 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>> 1335266704.416      1 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>> 1335266704.418      1 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>> 1335266704.418      0 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>> 1335266704.420      0 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>> 1335266704.423      0 192.168.8.39 TCP_REFRESH_UNMODIFIED/200 601 GET
>> http://158.1.4.2/elastica.html - DIRECT/158.1.4.2 text/html
>>
>>
>>
>> The TCP_REFRESH_UNMODIFIED request status makes me think that squid is
>> serving me the page from its cache and not retrieving it from its
>> actual source. Am i right?
>
>
> Yes and no.
>  REFRESH --> origin has been contacted to ensure the response is fresh.
>  UNMODIFIED --> the origin said no change.
>  200 --> full cached object was returned to client.
>
> Squid is both servicing out of cache, AND contacting the origin as you
> require. All that is being optimized there is that the body data is not
> taking up bandwidth (and byte transfer time) between origin and Squid.
>
>
> Performance and capacity of a proxy is not as simple as how much lag it
> adds. A proxy can both add or subtract lag, in multiple diffferent ways.
>
> You can break down the tests into three basc performance levels. From worst
> to best they are:
>  * non-cacheable: every request goes all the way to the origin and every
> response comes back in full from the origin.
>  * validation (stale client cache): every request goes all the way to the
> origin, only a revalidate response (no body data) is transmitted
> origin->Squid, full body squid->client.
>  * validation (fresh client cache): every request goes all the way to the
> origin, only a revalidate response (no body data) is transmitted
> origin->Squid->client.
>  * cachable: requests only  go as far as Squid. Serviced out of cache with
> full body data.
>  * cachable revalidate: requests only  go as far as Squid. Serviced out of
> cache with only a revalidate response (no body data) transmitted
> Squid->client.
>
> Across these levels Squid speed varies from hundreds of request per second
> (non-cacheable) up to hundred of thousands per second (cache+validate).
>
> Squid caching types complicate things even further, by being extremely fast
> (RAM cache) or variably slow (disk cache) on retrieval I/O cycles and thus
> time to push out to the client for the latter 4 cases.
>
>
> Amos

-- 
Regards,
-Ahmed Talha Khan