On 01/20/2011 01:59 PM, Phil Oester wrote:
> I recently upgraded a proxy farm from 2.7 to 3.1, and saw
> a huge performance drop. For validation purposes, I setup
> a test box with a local webserver and different versions of
> Squid to compare performance. The test involved transferring
> a single 500MB file (output to /dev/null). I also included
> tinyproxy and Apache for comparison purposes. Results are
> as follows (average of 5 runs):
>
> 3.2.0.4: 43 MB/s
> 3.1.10: 47 MB/s
> 3.0 stable 25: 53 MB/s
> 2.7 stable 9: 120 MB/s
> 2.6 stable 23: 123 MB/s
> tinyproxy 1.6.5: 146 MB/s
> apache 2.2.17: 210 MB/s
> direct: 725 MB/s
>
> As one can see, the drop from 2.x to 3.x is huge,
Please make sure you understand the limitations of this kind of test. It
does illustrate a problem, but we need to be careful: Squid (any
version) is not "seven times worse" than going direct, for most
practical purposes, even though your test "shows" that it is.
> likely due to the C++ refactoring.
C++ refactoring itself has nothing to do with this.
> And each successive 3.x version has continued the downward trend.
Just like each consecutive Squid2 version you measured...
The downward trend is really there though, and we even know some
specific changes or revisions that significantly decrease performance.
For example:
Rev "Performance"
v3.0 start in trunk:
8643 5781
8650 5764 0%
8655 5726 1%
r8657: Added IPv6 support:
8660 4803 -17%
8670 4793 -17%
8700 4816 -17%
8750 4790 -17%
r8800: Added AsyncCalls:
8850 4549 -21%
8959 4567 -21%
8965 4580 -21%
8970 4593 -21%
8990 4593 -21%
9030 4572 -21%
9100 4575 -21%
XXX: unknown change(s):
9606 4733 -18% +3%
XXX: more unknown change(s):
11120 3393 -41% -28%
Just like your test, the above performance factors are not really
meaningful as absolute numbers, but they do indicate where some of the
problems are located. Please note that not all such problems have direct
solutions (sometimes a specific overhead is worth paying for), but Squid
is so far from optimal performance that it should always be possible to
compensate elsewhere if needed.
> So my question is whether any work is being done on improving
> performance of the 3.x series?
Yes, there are several ongoing projects to
(a) identify regressions and
(b) fix them if possible.
The table above is an example of (a). For an example of (b), see the
recent discussions here on how to minimize performance impact of IPv6
changes.
> The performance drop of > 50% is quite noticable for end users.
> Is there anything I can do to help?
Absolutely! We need help with both (a) and (b). If you prefer to work on
the testing side, we need more tests to complete the table above, and
identify remaining unknowns. If you prefer development, please help
fixing identified regressions.
And since most of our time is spent on other bugs and features, help
with code reviews, bug triage, and other regular project activities can
free cycles for performance work. If you cannot do this kind of work
yourself, but can sponsor any of the above, then it can speed things up
as well.
Cheers,
Alex.
Received on Fri Jan 21 2011 - 21:21:05 MST
This archive was generated by hypermail 2.2.0 : Sat Jan 22 2011 - 12:00:06 MST