On 10/13/2010 04:21 AM, Peter Payne wrote:
> BENCHMARKS
>
> Firstly, I wanted to address the benchmark questions as it made me
> curious as to whether there really was an advantage in using /dev/poll.
> I used the Apache Bench tool (that comes with HTTPD) to do my benchmarks.
>
> I compiled a 32-bit Solaris 5.10 x86 of Squid version 3.1.8, and another
> Squid version 3.1.8 with my patches. I shall call them "unpatched Squid"
> and "patched Squid" respectively. Note that "unpatched Squid" was using
> ordinary poll() and "patched Squid" was using /dev/poll.
>
> Where I used Apache bench with 1 simultaneous connection or even 8,000
> simultaneous connections there was little difference between "unpatched
> Squid" and "patched Squid". When all connections are busy there is no
> performance gain.
>
> However the test that proved the most striking difference was
> pre-establishing 8,000 TCP socket connections to Squid using a basic
> Perl script. Then running Apache Bench with 1 connection making 100,000
> keep-alive'd requests.
>
> unpatched Squid (using poll):
> 2min23sec CPU user-time
> 171sec to process 100000 Apache Bench queries
>
> patched Squid (using /dev/poll):
> 0min22sec CPU user-time
> 25sec to process 100000 Apache Bench queries
> Clearly /dev/poll has a significant performance gain where there are
> many idle TCP socket connections.
On 10/13/2010 04:25 PM, Amos Jeffries wrote:
> Oooh... Speed.
Not really, at least not if you define "performance" or "speed" as
"ability to sustain an X requests/second load".
The above test is a classic best-effort test that, by design, cannot
measure proxy's ability to handle load because its offered request rate
depends on measured response time. During such a test, Squid drives the
benchmark rather than the benchmark driving Squid.
There are many real-world examples where a faster product (for any
practical definition of "faster") would show drastically worse results
during such a test.
What the test does tell you is that an idle Squid became faster at
processing a single transaction after the patch. "Significant
performance gain" and similar conclusions are premature after a
best-effort test like this one.
Please do _not_ interpret my comments as negative towards the patch
itself. I just want to minimize the chance that others will start
running similar tests and jumping to the wrong conclusions regarding
their own optimization ideas.
Thank you,
Alex.
Received on Tue Oct 19 2010 - 17:41:01 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 20 2010 - 12:00:05 MDT