The Barracuda Server's HTTP Engine and Sockets Used

The Barracuda Server's HTTP server engine is designed to keep memory usage at a fixed amount both in the HTTP server engine and the TCP/IP stack. The maximum number of sockets used by the HTTP server engine is by default set to a low value (16), which is sufficient to support one modern browser. At the time of this writing, some browsers use up to 13 concurrent connections. You can change the default value by calling HttpServerConfig::setNoOfHttpConnections.

The HTTP server engine is designed to minimize the possibility of having sockets entering the TCP state TIME_WAIT since having sockets in this state can have a negative impact on the TCP/IP stack's performance and resource use. See the following two articles on more information on the impact of having a server with many connections in the TIME_WAIT state: article.

The HTTP server engine minimizes having sockets entering the TCP state TIME_WAIT by not closing socket connections unless it is forced to do so. A HTTP 1.1 socket can be in three states: not-connected, connected and in use, connected and idle. Idle HTTP 1.1 connections can be closed and the server normally leaves this decision to the client. Most HTTP clients close idle connections after a short idle time. A socket ends up in the TIME_WAIT state at the server side if the HTTP server engine is forced to close the connection such as when the HTTP engine's socket pool is exhausted and if socket accept fails (TCP/IP stack resource depletion).

You can increase the HTTP engine's socket pool size by calling HttpServerConfig::setNoOfHttpConnections; however, you must make sure the TCP/IP stack can handle the number of connections. The more connections the server can use, the less is the likelihood of having sockets closed by the server and having sockets in the TIME_WAIT state. The HTTP server engine can also serve more concurrent HTTP clients when increasing the socket pool size.

You should not increase the HTTP server engine's socket pool size beyond the size available in the TCP/IP stack and the TCP/IP stack interface. In particular, when using the SoDisp Barracuda Server porting layer for BSD, make sure the socket pool size is less than the maximum number of connections accepted by the BSD socket function select. The Windows TCP/IP stack's version of select can support a maximum of 64 connections ( can be increased ) and Linux BSD select can support a maximum of 1024 connections. Note that we support multiple porting layers for SoDisp for various operating systems. For Linux, we support BSD and epoll. The SoDisp epoll socket dispatcher can support up to 212,000 concurrent connections.

When using a TCP/IP stack with limited resources, be careful with using socket connections that are not controlled by the HTTP server engine such as sockets created using the high level Lua socket API, HTTP client connections, WebSocket connections, and EventHandler connections. These connection types are unbound and not controlled by a configurable maximum amount in the Barracuda Server. All socket connections used in a Barracuda Server are using the same socket dispatcher (SoDisp) and are limited by the limitations imposed by this porting layer and the TCP/IP stack being used.

Note: in many TCP/IP stacks, the time a socket stays in the TIME_WAIT state can be changed. We recommend reducing this time if you run into resource issues in your TCP/IP stack.