From owner-freebsd-questions@FreeBSD.ORG Mon Mar 3 19:50:44 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47549106566B for ; Mon, 3 Mar 2008 19:50:44 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BA0178FC26 for ; Mon, 3 Mar 2008 19:50:43 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.2/8.14.2) with ESMTP id m23Jobf3019667; Mon, 3 Mar 2008 19:50:37 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.4.4 smtp.infracaninophile.co.uk m23Jobf3019667 Authentication-Results: smtp.infracaninophile.co.uk; dkim=hardfail (SSP) header.i=unknown Message-ID: <47CC568D.2000007@infracaninophile.co.uk> Date: Mon, 03 Mar 2008 19:50:37 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.12 (X11/20080302) MIME-Version: 1.0 To: Bill Moran References: <975190.87342.qm@web54306.mail.re2.yahoo.com> <20080303133609.458b5635.wmoran@potentialtech.com> In-Reply-To: <20080303133609.458b5635.wmoran@potentialtech.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Mon, 03 Mar 2008 19:50:38 +0000 (GMT) X-Virus-Scanned: ClamAV 0.92.1/6095/Mon Mar 3 17:07:58 2008 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on happy-idiot-talk.infracaninophile.co.uk Cc: Patrick Dung , freebsd-questions@freebsd.org Subject: Re: Maximum number established TCP connection X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 19:50:44 -0000 Bill Moran wrote: > In response to Patrick Dung : > >> Hello >> >> I would like if there is a (countable) limit for the max TCP connection >> of a Apache web server. >> >> Suppose: >> 1. An apache web server serves a very big iso file. >> 2. 5000 people tried to connect to the apache server to get the iso >> file. >> 3. They connect to the server gradually (not 5000 people starting at >> the same moment). So that there will not be a problem caused by the TCP >> backlog limit. >> 4. There will be 5000 established TCP connections. >> >> Is it true that FreeBSD could handle 'unlimited' established TCP >> connections as long as it has enough CPU power and memory? > > The FreeBSD limit on the number of open TCP connections is significantly > higher than the Apache limit on the number of concurrent HTTP sessions. > I believe Apache has a hard limit of 256. That's a compile-time option in apache-1.3.x -- you can set APACHE_HARD_SERVER_LIMIT in /etc/make.conf to override the default of 512 if required. However in apache-2.2.x it seems the limits are imposed entirely by the MPM settings in httpd.conf -- at least, I cannot find any tunables in the port Makefiles. Generally the practical limit on the number of apache processes is the amount of available RAM. You want enough processes to fill up the memory, but no more -- so the system does not begin to swap. If the system does start swapping, performance will suffer for all users, new connections will begin to pile up and generally the whole thing will come to a grinding halt. With a maximum limit on the number of processes -- which corresponds to the total number of simultaneous active clients -- excess incoming connections are queued up until a process becomes available to deal with them. However, 5000 simultaneous apache processes is probably still too much, even if your server has oodles of RAM and you make strenuous efforts to slim down apache to the smallest possible image size. In such situations, smaller and lighter-weight HTTP servers such as nginx are more appropriate -- or else apply an aggressive inverse caching policy using such things as varnish or squid. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW