'Standard' vapor website drops 1.5% of requests, even at concurrency of 100!

[axello (Axel Roest)]

@wadetregaskis

But it's not clear to me if you can just do timeout count (as reported by wrk) times server response CPU time, to compute that loss delta. It might be that wrk times out some of those connections before the server's even started handling them, and maybe the server detects that the socket closed while it was in the accept queue and therefore never even does the Fibonacci calculation.

I do not understand that metric either. That's why I always report 'requests' vs 'timeouts'. The Socket Errors only appear on high load with the timeouts.

@wadetregaskis

Which reminds me - is wrk opening N persistent connections and using HTTP/1.1 pipelining, or is it actually opening a new TCP connection for every request? Because that will dramatically change the behaviour in some aspects.

Yes, the reason I used wrk, is that it uses pipelining. That's why ab (apachebench) had such terrible performance: it opened a new socket for each request. And then it overloaded the system by throwing

• socket: Too many open files
• apr_socket_recv: Connection reset by peer

errors.

I raised the ulimit -n to 10240, but still apr_socket_recv: Connection reset by peer (104) occurred occasionally.