wang.gaohao@xxxxxxxxxx wrote:
I read this at the end of
http://www.squid-cache.org/mail-archive/squid-users/201002/0795.html
I want to use squid as a reverse proxy,so I am interested in the squid
performance.
Can you post a detailed result about this lab test?
The test is a test about single machine or Cluster?
The record of the aiCache is just 25,000 rps,so your record is very
amazing.
Can you give me some viewpoint about squid and aiCache?
Thank you.
As I said it was for a lab test and _very_ artificial. The 300K results
was specifically from testing of the new accept() handler for Squid-3.1,
since I was facing complaints it could not get more than 5 concurrent
requests.
The 3rps was achieved by fetching google front page image (non
cacheable, ~4KB remote object).
I achieved that by using Squid-3.1 with a RAM cache, fetching a single
1KB object pre-stored in memory, with very short headers on both reply
and request. Using apachebench via the localhost interface (64KB RSS,
almost zero network stack IO delay) at some high concurrency just below
the cap point where Squid starts slowing from too many concurrent
requests (I forget exactly what that is right now, maybe 400-500
concurrency?). It took a few trials and that was what ab reported, give
or take a few Krps.
As soon as any real networking is attached, ie fetching from a box next
door, the rate drops to something around that 30Krps for the same
artificial memory-cached small object. I suspect that is simply due to
the kernel network stacks and buffering.
With real remote objects and URL were added in, thus incurring more
processing delays, it drops down to below 1Krps in line with the real
benchmarks that are starting to appear for Squid.
I guess, in theory Squid could process that many new requests in real
use, but time to supply would be vastly inflated as transfer resources
went into accepting new requests.
The point was that lab tests produce a wide variety of results,
depending on what is tested.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.1
