Nginx & long poll: Best practices to reduce memory and bandwidth footprint

Can someone please answer this question on serverfault.com?

-Quintin

Posting the contents inline. Can someone review this?

I use nginx in this mode for BOSH and chat clients along with gzip.

location ~* /http-bind/ {
proxy_buffering off;
keepalive_timeout 55;
access_log off;
tcp_nodelay on;
proxy_pass http://x.x.x.x:1111;
}

Is this the best approach to managing long polling in nginx.

I also use just one worker process for altogether for web & chat (single
CPU). Is that fine?

-Quintin

On 4 November 2011 05:15, Quintin P. [email protected] wrote:

 proxy_pass http://x.x.x.x:1111;

}

Is this the best approach to managing long polling in nginx.

I also use just one worker process for altogether for web & chat (single
CPU). Is that fine?

It looks fine. Use that until you have a performance problem, and then
gather evidence identifying your bottleneck before changing anything.

You might as well start with n worker processes though, where n is the
number of cores on your CPU. Give yourself a few thousand
worker_connections, because you’ll have a relatively large number of
relatively idle sockets.

Long-polling is very simple and nginx is good at it. I would advise not
to
try to fix anything until you find a real problem.

Thomas

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs