[squid-dev] Sad performance trend

Alex Rousskov rousskov at measurement-factory.com
Tue Sep 6 17:43:29 UTC 2016


On 09/06/2016 08:27 AM, Amos Jeffries wrote:
> On 27/08/2016 12:32 p.m., Alex Rousskov wrote:
>>         W1  W2  W3  W4  W5  W6
>>   v3.1  32% 38% 16% 48% 16+ 9%
>>   v3.3  23% 31% 14% 42% 15% 8%
>>   v3.5  11% 16% 12% 36%  7% 6%
>>   v4.0  11% 15%  9% 30% 14% 5%

> That trend goes all the way back to at least 2.6. Which is a bit weird,
> since it contradicts the total request-per-second capacity we have been
> watching in polygraph results.

I do not know what you mean by "total request-per-second capacity", but
I most likely have not been watching it. Is there a historical results
table for that measure that I can study?


> The speed per request goes down and the number that can be handled rises.

Even if concurrent transactions handling has been improving (and that is
a big if -- I have no data to back it up), it does not excuse the
significant worsening of per-transaction performance IMO.


> As far as my simple observations have been, the per-request slowdown
> correlates to the amount of code being added (ie new features) and also
> to the amount of AsyncCalls involved with the request handling (where
> more AsyncCall is more latency).

Additional code obviously slows things down, but the existing rate of
adding new features/async calls does not seem to match the magnitude of
the measured performance decline, especially for the basic code paths
tested by these micro tests. For things to be getting worse in such a
manner, we probably have to make the old code/features worse (in
addition to adding new features/async calls) and/or adding those new
features in a terribly inefficient way.

Alex.



More information about the squid-dev mailing list