Re: [Nethttpd-plex] Poor performance on FreeBSD 8.2

Matías,

I can confirm that I also get poor performance with your curl tester,
but good performance with other utilities. And it is easy to explain.

Your tester plays a strict ping/pong game, i.e. the next request is
first sent when the previous is done. The siege tool, however, uses
pipelining to get better performance. This means a certain number of
requests are sent in sequence without waiting for replies (i.e. the
request sending is a certain number of messages ahead to response
reception). (Look here: http://en.wikipedia.org/wiki/HTTP_pipelining)

The difference is enormous, but is completely an artifact of the testing
method. The transport time for messages is not negligible, even for
local-loopback transport, and by default there are TCP options in effect
that artificially delay the messages in order to reduce the number of
Internet packets (Nagle algorithm). Trying TCP_NODELAY (on both sides)
would be interesting, also a non-TCP transport (e.g. Unix domain sockets
- should be easy with nethttpd, but I don't know whether curl allows
it).

I suspect that your self-written server benefits from shutting the
connection down immediately. The kernel knows then that no more data
will come.

Gerd


Am Donnerstag, den 07.07.2011, 14:40 -0300 schrieb Matías Giovannini:
> I've migrated to Debian Lenny, and even though I see higher throughput
> compared to FreeBSD 8, there is a huge discrepancy between static file
> serving and dynamic services in Nethttpd:
> 
> 
> $ ./curl_test -v -m g -n 100
> 'http://127.0.0.1:4444/share/misc/magic.mime'
> Total time: 0.100 s (996.35 req/s)
> cURL  time: 0.100 s (1000.11 req/s)
> successes: 100/100
> $ ./curl_test -v -m g -n 100 'http://127.0.0.1:4444/adder'
> Total time: 3.961 s (25.25 req/s)
> cURL  time: 3.960 s (25.25 req/s)
> successes: 100/100
> 
> 
> I've measured my own dynamic handler and its activation is
> consistently under 1 ms, so I'm confident that it is not the handler
> code that is holding my throughput back.
> 
> 
> Maybe something to do with Netcgi? I'd love to hear your opinions.
> 
> 
> Regards,
> Matías.
> 
> On Tue, Jul 5, 2011 at 7:15 PM, Stéphane Legrand <[email protected]>
> wrote:
>         Le mardi 05 juillet 2011 à 17:30 -0300, Matías Giovannini a
>         écrit :
>         > Stéphane,
>         > it's odd, as testing the cURL script against a minimal
>         server I get
>         > good throughput:
>         >
>         >
>         > $ ./curl_test -v -n 1000 'http://127.0.0.1:9999/'
>         > Total time: 0.149 s (6699.49 req/s)
>         > cURL  time: 0.122 s (8206.21 req/s)
>         > successes: 1000/1000
>         >
>         
>         
>         I tried this server with the curl client. I also get much
>         higher request
>         rate (around 1000 req/sec).
>         
>         I really don't know. Have you tried to play with the curl
>         options,
>         particularly the TCP_NODELAY one ?
>         
>         
>         Regards,
>         Stéphane.
>         
>         
>         
>         
> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________ Ocamlnet-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel


-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
[email protected]          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Ocamlnet-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel