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

Gerd,

thank you for your response. I understand your explanation, except that I
still can't account for the enormous difference in throughput between
Nethttpd_services.dynamic_service and Nethttpd_services.file_service (if I
understand the code correctly, the latter handles by returning a `File value
to the engine, while the former generates dynamic content with
Netcgi.cgi_activation#out). I'm preoccupied with trying to extract the
maximum sequential speed possible out of Nethttpd since the client does no
pipelining, and I have essentially no control over it.

Kind regards,
Matías.

On Thu, Jul 7, 2011 at 4:11 PM, Gerd Stolpmann <[email protected]>wrote:

> 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