cand @ gsoc

The CGI plugin was initially blocking, because that was the easiest way to write it. This week I’ve so far worked on moving it to the event-based model.

Initial results were terrible, while I could get it stable, its performance was only 50-60% of that of the blocking model, latency was doubled, and it came with 250 more lines of code.

Today, investigating showed that epoll was firing some 2k pointless write events when we had nothing to write. The couple additional syscalls to remove the wait for write events when we know we don’t need them were quite a win.

The latest CGI plugin is event-based, stable, and better than the blocking one, not counting lines of code though (they increased to 300 ;)).

Performance increased 18% for shell scripts, 88% for the C app, and 26% for PHP. Latency is less than half of the blocking model’s one, it’s sub-10ms now (vs 15-20ms).

Transactions/sec:

For comparison, static pages get 29k on the same setup.

I asked on #nginx (freenode) why nginx scaled badly (5% improvement) when going from 1 to 5 workers.

The consensus was that nginx is designed so that every worker calls accept(). I think that this is a bad design decision, but given a modern linux host, it was said that this is no longer an issue.

Nginx has an option to disable the mutex controlling accept(), accept_mutex off in the event block of the main config file. Given how important this one option is, I’m extremely disappointed that

• It’s not the default on suitable systems
• It’s not even documented in the shipped config files

This one option is why nginx scales terribly in its default configuration. When compiled on a suitably new linux system, ideally it would turn it off by default. And in all cases, it should be documented in the shipped config files, even if commented out.

Tested with 5 workers and accept_mutex off, nginx got 28000 +- 0.2%.

This puts nginx up to the expected numbers.

Curious from the even results on the Raspberry Pi, I thought it was time to test nginx on the 6-core comp too (Phenom II X6 2.8GHz).

The website was the static one shipped with monkey, containing html and one picture. Siege was run with the usual settings, benchmark mode, 10 concurrent threads and 10 seconds of test time.

siege -c10 -t 10S -b localhost:1234

Versions:

• nginx 1.2.0

• Monkey ea83cb6860f9555011a4959294bd7d765b1fe533 plus some small fixes

Monkey was tested only in the default config (5 workers). Nginx was tested both in its default config (1 worker) and with 5 workers, to gain even ground with Monkey.

All numbers are averaged over three runs. Without further ado:

Woah.

Given the equal results under the Pi, I wasn’t expecting this. Further, it was surprising how little nginx gained from moving to 5 workers (+1 management thread, all on a 6-core cpu).

Here’s the raw data for one of the three runs:

      Date & Time,  Trans,  Elap Time,  Data Trans,  Resp Time,  Trans Rate,  Throughput,  Concurrent,    OKAY,   Failed

nginx default, 1 worker

2012-05-04 18:02:16, 122599,       9.75,         159,       0.00,    12574.26,       16.31,        9.34,  122599,       0

nginx 5 workers

2012-05-04 18:04:15, 136634,       9.99,         177,       0.00,    13677.08,       17.72,        9.34,  136635,       0

monkey default

2012-05-04 18:47:07, 254261,       9.01,         330,       0.00,    28219.87,       36.63,        9.33,  254261,       0