On Tue, Apr 24, 2012 at 5:37 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
