Nginx performance data

[James Read]

On Fri, Jan 14, 2022 at 12:47 AM James Read <jamesread5737 at gmail.com> wrote:

>
>
> On Sun, Jan 9, 2022 at 12:47 AM Reinis Rozitis <r at roze.lv> wrote:
>
>> > Otherwise why is my application running into such performance limits as
>> mentioned in this question on stackoverflow
>> https://stackoverflow.com/questions/70584121/why-doesnt-my-epoll-based-program-improve-performance-by-increasing-the-number
>> ?
>>
>> You are testing something (public third party dns servers) you have no
>> control over (how can you be sure there are no rate limits?) with third
>> party libraries without actually measuring/showing what takes up your time.
>> That's not the best way to test low level things.
>>
>
> I just succeeded in modifying the wrk source code so that is connects with
> multiple servers rather than just the one. I can confirm that it gets the
> same throughput as with one host. So I take back my comments about there
> being a difference between one host simulating many being different to an
> actual test with many clients. There must be a problem with my epoll
> implementation because the modified wrk codebase works just fine.
>
>
I've done some more playing around with the wrk source code. It turns out
that wrk was reusing connections and for this reason was able to achieve
high throughput. When you change the source code and force wrk to only use
a connection once (the very situation it should be trying to simulate) the
throughput drops off a cliff. I'm beginning to think there may be a problem
with the Linux TCP/IP stack. I haven't tested this on BSD (yet).

James Read


> James Read
>
>
>>
>> I would suggest to at minimum do at least 'strace -c' to see what
>> syscalls takes most of the time.
>>
>> But that's something out of scope of this mailing list.
>>
>> rr
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20220123/5a0ff9a1/attachment.htm>