<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 6, 2016 at 6:43 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 09/06/2016 08:27 AM, Amos Jeffries wrote:<br>
> On 27/08/2016 12:32 p.m., Alex Rousskov wrote:<br>
</span><span class="gmail-">>>         W1  W2  W3  W4  W5  W6<br>
>>   v3.1  32% 38% 16% 48% 16+ 9%<br>
>>   v3.3  23% 31% 14% 42% 15% 8%<br>
>>   v3.5  11% 16% 12% 36%  7% 6%<br>
>>   v4.0  11% 15%  9% 30% 14% 5%<br>
<br>
</span><span class="gmail-">> That trend goes all the way back to at least 2.6. Which is a bit weird,<br>
> since it contradicts the total request-per-second capacity we have been<br>
> watching in polygraph results.<br>
<br>
</span>I do not know what you mean by "total request-per-second capacity", but<br>
I most likely have not been watching it. Is there a historical results<br>
table for that measure that I can study?<br>
<span class="gmail-"><br>
<br>
> The speed per request goes down and the number that can be handled rises.<br>
<br>
</span>Even if concurrent transactions handling has been improving (and that is<br>
a big if -- I have no data to back it up), it does not excuse the<br>
significant worsening of per-transaction performance IMO.<br>
<span class="gmail-"><br>
<br>
> As far as my simple observations have been, the per-request slowdown<br>
> correlates to the amount of code being added (ie new features) and also<br>
> to the amount of AsyncCalls involved with the request handling (where<br>
> more AsyncCall is more latency).<br>
<br>
</span>Additional code obviously slows things down, but the existing rate of<br>
adding new features/async calls does not seem to match the magnitude of<br>
the measured performance decline, especially for the basic code paths<br>
tested by these micro tests. For things to be getting worse in such a<br>
manner, we probably have to make the old code/features worse (in<br>
addition to adding new features/async calls) and/or adding those new<br>
features in a terribly inefficient way.<br></blockquote><div><br></div><div>Hi,</div><div>  As you have obviously spent some effort in this, would it be possible to share these benchmarks with the larger community, possibly by leveraging the automations we are already using?</div><div><br></div><div>-- </div></div><div class="gmail_signature">    Francesco</div>
</div></div>