Nginx Serving Static Files Way Too Slowly

Question

I asked this on Stack Overflow, but maybe it's more of a question for the SF crew.

So there have been lots of articles like this one recently, extolling the virtues of Django Static Generator when used in combination with a light front-end Web server. It makes a whole lot of sense to me.

However, I get nothing like the results that other people are reporting -- thousands of requests per second -- and I don't know why that is.

I'm getting ready to launch a redesign of my newspaper's Web site. I've got it using Static Generator on a test server right now. And when I run Apache Bench on a particular static page, I get pretty miserable results:

ab -c 10 -n 1000 http://journal.streamlister.com/news/

Concurrency Level:      10
Time taken for tests:   53.011 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      21281212 bytes
HTML transferred:       21067360 bytes
Requests per second:    18.86 [#/sec] (mean)
Time per request:       530.107 [ms] (mean)
Time per request:       53.011 [ms] (mean, across all concurrent requests)
Transfer rate:          392.04 [Kbytes/sec] received

I'm watching top on the server while the siege is on, and I can see that it's not hitting Apache or the database server at all. So it is, in fact, serving the cached page. Nginx is running, but it never gets above 2% memory usage. CPU remains about 95 percent idle.

What am I doing wrong? Could I have misconfigured nginx somehow? My main config file is pasted below; the include specific to this site is pretty much a carbon copy of the sample config on the Static Generator home page. I'm running Ubuntu 9.10 on a Slicehost 256k slice.

user not_my_real_username;
worker_processes  4;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  8192;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  0;
    #keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Answer 1

You can increase nginx performance, just adding next options to config:

   http {

      open_file_cache max=1000 inactive=300s;
      open_file_cache_valid 360s;
      open_file_cache_min_uses 2;
      open_file_cache_errors off;

    }

Answer 2

Your nginx is actually serving files at a reasonable rate. From an external machine, I was able to get 371 requests per second with ab on one of the CSS files on that page.

You are testing the whole page, which means you're making 22 requests on it. I was able to get around 40 requests per second when benching http://journal.streamlister.com/news/.

It could probably be faster, but you're on a VPS where you're sharing CPU and disk I/O with others.

Answer 3

I would have to agree with gekkz that it might be your VPS. I just did an ab test on one of my static files and got:

Total transferred: 11203000 bytes
HTML transferred: 10861000 bytes
Requests per second: 674.14 [#/sec] (mean)
Time per request: 14.834 [ms] (mean)
Time per request: 1.483 [ms] (mean, across all concurrent requests)
Transfer rate: 7375.39 [Kbytes/sec] received

this was a css file. I'm also on a VPS from linode.com. A recent blog post of theirs shows some tests done on various VPSs that might be of interest.

I just looked and my config file is only a little different. I have 2 procs setup, 1024 connections and I have keep_alive turned on.

Answer 4

Your test parameters are the problem I think. With a max concurrency of 10, but each page taking ~500 ms total to deliver, you will see at most about 20 requests per second.

Have you tested with higher concurrency levels using ab? (Note that ab is a really simplistic tool for load testing a web application, and can only really be considered a "microbenchmark"). You should also be benchmarking from a different machine of course, perhaps more than one other machine if bandwidth or memory are an issue.