Bill Moran wrote: > In response to Patrick Dung <[EMAIL PROTECTED]>: > >> 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 _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"