Http Server ⋅ Running on Production
- Set your
ulimit -n(maximum open file descriptors) high enough to manage all your connections. Recommended is at least
(Options->getConnectionLimit() + 100). [100 is an arbitrary number usually big enough for all the persisting file descriptors. If not enough, add more.]
- In case you are using a properly configured load-balancer in front of Amp’s HTTP servers, you should set the number of connections near to the maximum the host system can handle.
- Amp’s HTTP server has a static content server, which is acceptable for lighter loads (use some extension if you use it!), but for heavy loads, a CDN is recommended.
- Avoid a low
memory_limitsetting, it is one of the few things able to kill the server ungracefully. If you have a memory leak, fix it, instead of relying on the master process to restart it.
Defaults are chosen in a moderate way between security and performance on a typical machine.
- In debug mode HTTP server sends any debugging-related information and to the logger. Debug mode is disabled by default. To enable it, make sure you run HTTP server with debug mode option and set log level to
- The connection limit is important to prevent the server from going out of memory in combination with body and header size limit and (for HTTP/2) concurrent stream limit option.
- The connections per IP limit ratelimits the number of connections from a single IP, to avoid too many connections being dropped off. Be aware that websocket and HTTP/2 connections are persistent. It’s recommended to carefully balance the maximum connections per IP and the connection limit option. It just is a simple layer of security against trivial DoS attacks, but won’t help against DDoS, which will be able to just hold all the connections open.
- The connection timeout is a keepalive timeout. Conventional wisdom says to limit it to a short timeout.
- The body size limit is recommended to be set to the lowest necessary for your application. If it is too high, people may fill your memory with useless data. (It is always possible to increase it at runtime, see RequestBody::increaseSizeLimit).
- The header size limit should never need to be touched except if you have 50 KB of cookies.
- The chunk size is the maximum size of chunks into which the response body is sliced. A too low value results in higher overhead. A too high value impairs prioritization due to head-of-line blocking.
- The concurrent stream limit is the maximum of concurrent HTTP/2 streams on a single connection. Do not set it too high (but neither too low to not limit concurrency) to avoid trivial attacks.
- The frames per second limit is the maximum number of frames a HTTP/2 client may send per second before being throttled. Do not set it too high (but neither too low to not limit concurrency) to avoid attacks consisting of many tiny frames.
- The minimum average frame size is the size of the largest frame payload that the sender is willing to receive. The value advertised by an endpoint MUST be between the default value (16KB) and the maximum allowed frame size (16MB), inclusive. Smaller frame size enables efficient multiplexing and minimizes head-of-line blocking.
- The compression is recommended to be enabled. Compressing responses sent to clients can greatly reduce their size, so they use less network bandwidth.
- The allow HTTP/2 upgrade is disabled by default because you can only upgrade to an insecure (cleartext) HTTP/2 connection.