Hello!

On Sat, Jan 12, 2013 at 12:19:15PM -0800, JB Hobbs wrote:

> > return 444;
>
> Thanks. I tested this. I think in some ways it is worse.  In one
> way it seems better because with 444 I do not get a 408 from
> Nginx 60 seconds later.
>
> However, sending the 444 causes Chrome to try multiple times in
> a row. For instance just entering https://mydomain/ one time in
> the browser and not refreshing the page at all gives this:

Yes, for https hosts most browsers retry with various workarounds
if connection is closed, and use of "return 444" with https is
probably not a good idea.

[...]

> I am wondering if I am concerning myself too much with this 60
> second delay before nginx closes the connection. I can probably
> use client_header_timeout at 15s and still have that be safe and
> so the connection doesn't stay more than 15 seconds before Nginx
> closes it out.  But I still wonder if having this connection
> stick around is wasting resources?

It is, but a) most likely you wouldn't even notice, and b) you
anyway can't avoid it completely.

> > This depends on the OS you are using.  E.g. on FreeBSD "vmstat -z" 
> > will show something like this:
>
> > This isn't a problem if you have properly tuned 
> > system and enough memory, but if you are trying to keep lots of
> > connections alive - you may want to start counting.
>
> Sorry I should have specified I am on Fedora Core 17. It has a
> vmstat but no -z option?  Anyway, in looking at the output, how
> can one determine whether the amount of sockets and such being
> held is nearing the OS limits?

Sorry, I'm not familiar with Linux and can't help. Google returns
about 1 mln results on "linux tuning c10k" query though.


--
Maxim Dounin
http://nginx.com/support.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx