Re: [Nethttpd-plex] Poor performance on FreeBSD 8.2
Stéphane Legrand <[email protected]> Mon, 11 Jul 2011 22:23:17 +0200
| Newsgroups | gmane.comp.lang.ocaml.lib.net.devel |
|---|---|
| Message-ID | <[email protected]> |
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