G-WAN assumptions: Part of truth/lies?

Hello,

Documentating myself on proper benchmarking, I ran into the following
page:

Their conclusion is that their product is the best of all. Well, ‘of
course’ one might say… ;o)

What surprised me most that they claim to use less resources AND perform
better. That particularly strikes me because usually ot favor one side,
you
take blows on the other one.

To me, the problem of such tests is that they are a mix of
realistic/unrealistic behaviors, the first being invoked to justify
useful
conclusions, the latter to make a specific environment so that features
from the Web server (as opposed to other components of the
infrastructure)
are tested.

They are arrogant enough to claim theirs is bigger and paranoid enough
to
call almost every other benchmark biased or coming from haste/FUD
campaigns. That is only OK if they are as pure as the driven snow…

I need expert eyes of yours to determine to which end those claims are
grounded.

Particular points:

  • Is their nginx configuration http://gwan.com/source/nginx.conf
    suitable
    for valid benchmark results?
  • Why is your wrk test tool built in such way in pre-establishes TCP?
  • Why is nginx pre-allocating resources so its memory footprint is large
    when connections are pre-established? I thought nginx event-based system
    was allocating resources on-the-fly, as G-WAN seems to be doing it. (cf.
    ‘The (long) story of Nginx’s “wrk”’ section)
  • Why is wrk (in G-WAN’s opinion) ‘too slow under 10,000 simultaneous
    connections’? (cf. ‘The (long) story of Nginx’s “wrk”’ section)

B. R.

One forgotten specific point I also wanted a reply upon:

  • Why is nginx’ latency that high (200ms) while serving the built-in
    nop.gif content? (cf. ‘The (long) story of Nginx’s “wrk”’ section)

B. R.

And of course, you should ask what the relevance of delivering a single,
100byte file a huge number of times actually has in real life, or where
useful things - like comparison of server side languages behind various
web servers - are tested.

And yes, any web servers latency should be approximately zero for
testing delivery of a static file locally ( also pointless ).

returning empty_gif, rather than nop.gif is also exercising internal
code, rather than just delivering a file, so the processing is not
comparable.

saving open file metadata may also help, but the test is so skewed and
unrealistic it’s not really worth the effort.

That’s just my view as a SysAdmin

On Sun, 2015-02-08 at 00:52 +0100, B.R. wrote:

    What surprised me most that they claim to use less resources


    thought nginx event-based system was allocating resources

nginx mailing list
[email protected]
nginx Info Page


Steve H. BSc(Hons) MIITP

Linkedin: http://www.linkedin.com/in/steveholdoway
Skype: sholdowa

On 08 Feb 2015, at 02:39, B.R. [email protected] wrote:

  • Is their nginx configuration suitable for valid benchmark results?

Probably you should disable “accept_mutex off”:
http://nginx.org/en/docs/ngx_core_module.html#accept_mutex

Because the mutex in combination with "multi_accept on:
http://nginx.org/en/docs/ngx_core_module.html#multi_accept
routes almost all requests just to one worker in this 100-bytes
micro-benchmark.