Maximum number established TCP connection

Matthew Seaman m.seaman at
Mon Mar 3 19:50:44 UTC 2008

Bill Moran wrote:
> In response to Patrick Dung <patrick_dkt at>:
>> 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.



Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
                                                  Kent, CT11 9PW

More information about the freebsd-questions mailing list