Re: [Nethttpd-plex] Poor performance on FreeBSD 8.2
Stéphane Legrand <[email protected]> Mon, 11 Jul 2011 23:12:56 +0200
| Newsgroups | gmane.comp.lang.ocaml.lib.net.devel |
|---|---|
| Message-ID | <[email protected]> |
Le lundi 11 juillet 2011 à 18:09 -0300, Matías Giovannini a écrit : > Very interesting numbers, Stéphane! May I ask what is the patch you > applied to add NODELAY to the server? The patch sent by Gerd Stolpmann. > > 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