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

Matías Giovannini <[email protected]> Mon, 11 Jul 2011 18:09:07 -0300
Newsgroups gmane.comp.lang.ocaml.lib.net.devel
Message-ID <CALzEXo90Z44D1NF8tB94_tS-UVcnVNN-BsepK+3di=e-_oTkOA@mail.gmail.com>
Very interesting numbers, Stéphane! May I ask what is the patch you applied
to add NODELAY to the server?

Regards,
Matías.

On Mon, Jul 11, 2011 at 5:23 PM, Stéphane Legrand <[email protected]> wrote:

> Le lundi 11 juillet 2011 à 11:20 +0200, Gerd Stolpmann a écrit :
> > 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.
> >
> > So, under Linux I see something that is even more weird. For static
> > files I get a difference between native and bytecode, but other than
> > expected: there is a three times better performance for bytecode.
> >
> > Experimentally, I set the TCP_NODELAY option in the server:
> >
> >   let nethttpd_factory1 =
> >     Nethttpd_plex.nethttpd_factory
> >       ~handlers:[ "adder", adder ]
> >       () in
> >   let nethttpd_factory2 =
> >     ( object
> >       method name = "nethttpd"
> >       method create_processor cc cf addr =
> >         let p = nethttpd_factory1 # create_processor cc cf addr in
> >         ( object
> >             inherit Netplex_kit.processor_base
> >                          (p :> Netplex_types.processor_hooks)
> >             method process ~when_done cont fd proto =
> >               Unix.setsockopt fd Unix.TCP_NODELAY true;
> >               p#process ~when_done cont fd proto
> >             method supported_ptypes =
> >               p#supported_ptypes
> >           end
> >         )
> >       end
> >     )
> >
> > This changed the game: adder is now even a bit faster, and I get around
> > 1350 req/s on my Laptop.
> >
> > Same under FreeBSD?
> >
> > Gerd
>
> Hello,
>
> I did some tests (see below) on FreeBSD. In summary :
>
> - Setting the TCP_NODELAY option for the server gives a huge performance
> boost !
>
> - The bytecode version is always slower than the native one.
>
> - At least for the curl library, setting or not the TCP_NODELAY option
> for the client has no effect.
>
>
> And for the details :
>
>
> Server: native, tcp_nodelay
>
>  Client: native, tcp_nodelay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 0.428 s (233.64 req/s)
>      cURL  time: 0.426 s (234.81 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 0.421 s (237.77 req/s)
>      cURL  time: 0.418 s (239.15 req/s)
>      successes: 100/100
>
>  Client: native, tcp delay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 0.490 s (204.26 req/s)
>      cURL  time: 0.487 s (205.32 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 0.361 s (276.72 req/s)
>      cURL  time: 0.359 s (278.32 req/s)
>      successes: 100/100
>
>
> Server: native, tcp delay
>
>  Client: native, tcp_nodelay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 10.235 s (9.77 req/s)
>      cURL  time: 10.232 s (9.77 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 10.116 s (9.89 req/s)
>      cURL  time: 10.113 s (9.89 req/s)
>      successes: 100/100
>
>  Client: native, tcp delay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 10.243 s (9.76 req/s)
>      cURL  time: 10.239 s (9.77 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 10.114 s (9.89 req/s)
>      cURL  time: 10.111 s (9.89 req/s)
>      successes: 100/100
>
>
> Server: bytecode, tcp_nodelay
>
>  Client: native, tcp_nodelay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 0.784 s (127.54 req/s)
>      cURL  time: 0.782 s (127.83 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 0.693 s (144.33 req/s)
>      cURL  time: 0.691 s (144.80 req/s)
>      successes: 100/100
>
>  Client: native, tcp delay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 0.832 s (120.13 req/s)
>      cURL  time: 0.829 s (120.61 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 0.649 s (154.01 req/s)
>      cURL  time: 0.647 s (154.53 req/s)
>      successes: 100/100
>
>
> Server: bytecode, tcp delay
>
>  Client: native, tcp_nodelay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 10.861 s (9.21 req/s)
>      cURL  time: 10.857 s (9.21 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 10.329 s (9.68 req/s)
>      cURL  time: 10.325 s (9.68 req/s)
>      successes: 100/100
>
>  Client: native, tcp delay
>
>    URL: http://127.0.0.1:4444/
>
>      Total time: 10.873 s (9.20 req/s)
>      cURL  time: 10.870 s (9.20 req/s)
>      successes: 100/100
>
>    URL: http://127.0.0.1:4444/adder
>
>      Total time: 10.315 s (9.69 req/s)
>      cURL  time: 10.312 s (9.70 req/s)
>      successes: 100/100
>
>
>
> Siege with native/tcp_nodelay server :
>
> Lifting the server siege...      done.
> Transactions:           14702 hits
> Availability:          100.00 %
> Elapsed time:           60.03 secs
> Data transferred:         31.30 MB
> Response time:            0.00 secs
> Transaction rate:        244.91 trans/sec
> Throughput:            0.52 MB/sec
> Concurrency:            0.79
> Successful transactions:       14703
> Failed transactions:             0
> Longest transaction:          0.05
> Shortest transaction:          0.00
>
>
> Siege with native/tcp delay server :
>
> Lifting the server siege...      done.
> Transactions:           15654 hits
> Availability:          100.00 %
> Elapsed time:           59.30 secs
> Data transferred:         33.32 MB
> Response time:            0.00 secs
> Transaction rate:        263.99 trans/sec
> Throughput:            0.56 MB/sec
> Concurrency:            0.75
> Successful transactions:       15655
> Failed transactions:             0
> Longest transaction:          0.07
> Shortest transaction:          0.00
>
>
> Siege with bytecode/tcp_nodelay server :
>
> Lifting the server siege...      done.
> Transactions:            5348 hits
> Availability:          100.00 %
> Elapsed time:           59.88 secs
> Data transferred:         11.38 MB
> Response time:            0.01 secs
> Transaction rate:         89.31 trans/sec
> Throughput:            0.19 MB/sec
> Concurrency:            0.99
> Successful transactions:        5348
> Failed transactions:             0
> Longest transaction:          0.16
> Shortest transaction:          0.00
>
>
> Siege with bytecode/tcp delay server :
>
> Lifting the server siege...      done.
> Transactions:            5372 hits
> Availability:          100.00 %
> Elapsed time:           59.51 secs
> Data transferred:         11.43 MB
> Response time:            0.01 secs
> Transaction rate:         90.27 trans/sec
> Throughput:            0.19 MB/sec
> Concurrency:            0.99
> Successful transactions:        5372
> Failed transactions:             0
> Longest transaction:          0.13
> Shortest transaction:          0.00
>
>
> Regards,
> Stéphane.
>
> >
> >
> > >
> > >
> > > 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