- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 21 Jun 2011 00:18:54 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Jan Starke <jan.starke@outofbed.org>, ietf-http-wg@w3.org
On Tue, Jun 21, 2011 at 10:05:49AM +1200, Adrien de Croy wrote: > > I think the inference was that some servers will struggle to provide > service to others when they maintain 30.000 idle connections. This is less and less common with todays hardware. Having been involved 10 years ago in designing an infrastructure that was able to support 10k concurrent users with Apache 1.3 as the first gateway, I remember how hard it was to support even a few thousands of concurrent connections on a server with 1-2 gigs of RAM at this time. Now common sizing for medium- sized servers are 32, 48 or even 64 gigs, and I know quite a bunch of people working in DCs who are used to buy that as the default hardware. Even with Apache 1.3, this allows you to reach such high numbers with some careful tuning. > But in the end, I don't see any real difference between sending the POST > or even just sending nothing. Agreed. It's similar to when the server is waiting for the end of headers for starting processing. > The server will have some sort of timeout. It might be a different > timeout used for waiting for anything vs waiting for a completion of a > POST message body. Yes that clearly is common and mandatory anyway. You can't rely on the OS only to kill the connections for you, as most default timeouts are much too large. > but I think the timeout in general will be long enough for many > connections to have been initiated. Indeed, which is why I was explaining the change that was made possible with RAM sizing nowadays. > Things that mitigate that are features like connection rate limiting > (per source IP), per-IP overall concurrent connection limits etc. I 100% agree. That's the most efficient solution but not all servers are able to do that. Still that's what the antiloris module was doing :-) Cheers, Willy
Received on Monday, 20 June 2011 22:19:22 UTC