Managing servers behind tempesta

Maximum Supported Connections

Optimal configuration for an HTTP server that is hidden behind a reverse proxy differs from optimal configuration for a server that serves clients directly. A server behind TempestaFW doesn't need to handle lots of connections from different clients. Instead it handles the exact number of connections created by TempestaFW. The number is specified in TempestaFW configuration file with the option conns_n of the directive server, e.g.:

server 192.168.0.1:8080 conns_n=64;

Most modern HTTP servers allow to configure the number of parallel threads or processes and the maximum number of connections that can be handled by a single thread/process. If each thread/process is configured to handle significantly more connections than the number of connections that will actually be active, then a single thread/process of a backend server may pull all the load. That would lead to misuse of resources. Thus, the configured number of connections across all threads/processes should be twice as large as the value of conns_n option in TempestaFW configuration. That would allow TempestaFW to successfully reopen connections closed by a backend server. As a result, the load handled by a backend server would be distributed fairly across all threads/processes.

E.g.: TempestaFW configuration:

server 192.168.0.1:8080 conns_n=256;

Nginx configuration:

worker_processes 4;

events {
    worker_connections 128;
    use epoll;
}

...

Connection Lifetime

TempestaFW maintains the exact number of connections with each backend server. If a server closes connections too soon, then the overall throughput will remain low under high load since TempestaFW-to-backend connections will be closed and reopened too often. For example, Nginx closes connections every 100 requests by default. To maximize the overall throughput the backend servers should be configured to keep connections open as long and possible. That would reduce the frequency of reopening TempestaFW-to-backend connections.

E.g., Ngnix configuration:

http {
    keepalive_requests 100000;
    ...
}

...

Request Timeout

Some HTTP servers can send 408 (Request Timeout) responses if a client doesn't send a request for long time. Since Tempesta FW establishes persistent connections with a backend server, the server can generate such responses, so you can find many records like the blow in your access log:

127.0.0.1 - - [22/Jul/2017:18:03:31 +0300] "-" 408 0 "-" "-"

It's recommended to disable request timeouts on a backend server side. For Apache HTTPD you can do this with following configuration option (read the official documentation for details):

RequestReadTimeout header=0 body=0