Dead code in accept

Serguei I. Ivantsov manowar at gsc-game.kiev.ua
Mon Aug 5 07:23:58 UTC 2013


1. Amount of instructions is somewhat bigger - about 500 bytes.
2. In high load you have thousands of accept()s per second.
3. No, I do not talk about adding some code, conversely - actually I want
remove dead code! :)

> Frankly, I don't see the need. We're talking about eliminating 4 or 5 CPU
> instructions per accept() call which only seems relevant if that's the
> only thing nginx does: but with HTTP pipelining this optimization is very
> insignificant as that already reduces the amount of accept() calls a lot.
> Also, you're talking about adding extra code which might add bugs (in
> extensions or the main code) and that's probably not worth it.
>
> About your benchmark: I assume you turned off keepalive and serve empty
> pages? Your 0.5% improvement will be more like 0.05% or less in reality.
>
> (I'm not a nginx developer though, so this post is only intended as
> advice)
>
> Tom
>
>
>> On 5 aug. 2013, at 08:58, "Serguei I. Ivantsov"
>> <manowar at gsc-game.kiev.ua> wrote:
>>
>> I think it is not a matter for trade - "dead code" - is bad programming
>> technique. And it should be eliminated in a fast web server.
>> Of course, general impact on overall performance is not significant, but
>> on function level it will be much noticeable. I can make a perf
>> profiling
>> test to get exact counters.
>>
>>> Hello!
>>>
>>> On Mon, Aug 05, 2013 at 12:15:04AM +0300, Serguei I. Ivantsov wrote:
>>>
>>> [...]
>>>
>>>> A little test with high volume of simple requests shows 0.5% overall
>>>> speed
>>>> improvement.
>>>
>>> Are you sure the numbers are significant?  Doing a ministat(1)
>>> analysis or similar is a good idea.
>>>
>>> http://www.freebsd.org/cgi/man.cgi?query=ministat&sektion=1
>>>
>>> --
>>> Maxim Dounin
>>> http://nginx.org/en/donation.html
>>
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>




More information about the nginx-devel mailing list