Performance plateau when keepalives enabled

powderhound nginx-forum at
Mon Mar 8 19:30:52 MSK 2010


I am benchmarking nginx 0.7.65 with httperf simulating a typical user visit which lasts max 10 seconds including pause time (i.e. hit page, grab inline elements such as images/css/js, pause, hit another page, etc.)  I am serving only static html and images/css/javascript.

httperf is running from two separate client machines both within 10ms ping from the webserver.  While httperf is running, I am also browsing the site on my workstation (200ms from the webserver) to see how it feels for a user.

When I run the benchmark with keepalive_timeout 0, nginx is very very fast and accepts new connections instantly.  Concurrent connections never goes above 5 since the benchmark clients are so close to the server.  However,

When I run the benchmark with keepalive_timeout 65, nginx is very slow (5-20 seconds delay) to accept new connections as soon as it reaches 1500 concurrent connections.  It plateaus here: it completes all the requests but it never exceeds approximately 1500 concurrent connections.

Is this normal?  Everywhere I read tells me to leave keepalive on and it shouldn't make any difference in nginx.  So is this a keepalive problem, or a problem handling >1500 concurrent connections?  What should I look at to fix it?

The box is 97% idle and it is not waiting on disk.

OS is Linux 2.6 with fs.file-max=65535 also before starting nginx, ulimit -n 65535 is called (from /etc/init.d/nginx)

There are no errors at all in the nginx error.log.  Not for file descriptors, or anything.  I watched error.log at "info" logging level and the only messages at all are the keepalive connection closing messages, which I believe are normal.

The nginx.conf has (amongst other things):

worker_processes 4;  # it's quad core machine
worker_rlimit_nofile 6144;
events {
    worker_connections 3072;
    use epoll;

http {
    sendfile on;
    tcp_push on;
    tcp_nodelay on;


Posted at Nginx Forum:,61482,61482#msg-61482

More information about the nginx mailing list