Hi all,
I've used wrk[0] to benchmark quark over a loopback interface.
With the latest code in git we have:
$ ./wrk -t1 -c200 -d30s
http://127.0.0.1
Running 30s test _AT_
http://127.0.0.1
1 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.57ms 9.15ms 1.60s 99.91%
Req/Sec 16.66k 2.16k 22.07k 65.87%
482946 requests in 30.00s, 6.53GB read
Socket errors: connect 0, read 0, write 0, timeout 29
Requests/sec: 16098.15
Transfer/sec: 222.93MB
$ ./wrk -t4 -c200 -d30s
http://127.0.0.1
Running 30s test _AT_
http://127.0.0.1
4 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 847.56ms 1.27s 3.26s 81.00%
Req/Sec 1.60k 1.49k 6.69k 51.82%
197048 requests in 30.05s, 2.66GB read
Socket errors: connect 200, read 0, write 0, timeout 1338
Requests/sec: 6558.11
Transfer/sec: 90.82MB
Obviously these numbers do not mean anything unless compared to
some other http server implementation.
From some quick testing that me and Hiltjo did yesterday, we found
that nginx is twice as fast. That's ok, quark has no optimizations in
place and can easily serve a few thousands of clients with static
content.
Quark uses fork() internally to handle the clients. I think that's a
bless in disguise. Any other technique (select, poll, epoll, etc.) will
require some small finite state machine to keep track of the connections,
recycle the appropriate file descriptors etc. More specific
interfaces like sendfile(), epoll() etc. are also going to cause problems
with portability.
I recommend sticking with fork() for now until we really really have to
move on to something else.
I will be looking at a poll() based implementation soonish to see how
it performs versus the complexity. I will post a patch here if I have
something worthwhile.
[0]
https://github.com/wg/wrk
Received on Thu Aug 14 2014 - 10:35:07 CEST