[dev] [quark] Current performance and ideas

From: Dimitris Papastamos <dp_AT_spl9.org>
Date: Thu, 14 Aug 2014 09:35:07 +0100

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
Running 30s test _AT_
  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
Running 30s test _AT_
  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

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

This archive was generated by hypermail 2.3.0 : Thu Aug 14 2014 - 10:36:07 CEST