HAProxy Enterprise Documentation 2.2r1

Compression

HTTP compression allows you to shrink the body of a response before it's relayed to a client, which results in using less network bandwidth per request. From a client's perspective, this reduces latency.

Enable compression

  1. In a frontend, backend, listen or defaults section, add a compression directive. Set its algo parameter to any combination of deflate, gzip, identity or raw-deflate. Responses will be compressed only if they are not already compressed:

    backend web_servers
       filter compression
       compression algo gzip
  2. Add a compression type directive, which specifies the MIME types to compress:

    backend web_servers
       filter compression
       compression algo gzip
       compression type text/css text/html text/javascript application/javascript text/plain text/xml application/json
  3. Optionally, add a compression offload directive, which states that HAProxy Enterprise will remove the Accept-Encoding header before forwarding a request to backend servers, which prevents the servers from performing compression, offloading that work to HAProxy Enterprise:

    backend web_servers
       filter compression
       compression algo gzip
       compression type text/css text/html text/javascript application/javascript text/plain text/xml application/json
       compression offload

Proxy-level settings

The following directives in a frontend, backend, listen or defaults section apply to compression:

compression algo <algorithm> ...

Sets the list of supported compression algorithms. Valid values include:

deflate

applies deflate compression with zlib format. Not recommended in combination with raw-deflate;

gzip

applies gzip compression;

identity

does not alter content at all; used for debugging purposes only;

raw-deflate

applies deflate compression without zlib wrapper. May be used as an alternative to deflate.

compression type <mime type> ...

MIME types to apply compression to, read from the Content-Type response header field. If not set, HAProxy Enterprise tries to compress all responses that are not compressed by the server.

compression offload

Instructs HAProxy Enterprise to remove the Accept-Encoding header from the request before forwarding it to the server. Thus, HAProxy Enterprise compresses the response, not the server.

Process-level settings

Add any of the following directives to the global section to affect compression:

maxcomprate <number>

Sets the maximum per-process input compression rate to <number> kilobytes per second. For each session, if the maximum is reached, the compression level will be decreased during the session. If the maximum is reached at the beginning of a session, the session will not compress at all. If the maximum is not reached, the compression level will be increased up to tune.comp.maxlevel. A value of zero means there is no limit, this is the default value.

maxcompcpuusage <number>

Sets the maximum CPU usage HAProxy Enterprise can reach before stopping the compression for new requests or decreasing the compression level of current requests. It works like maxcomprate but measures CPU usage instead of incoming data bandwidth. The value is expressed in percent of the CPU used by HAProxy Enterprise. In case of multiple processes (nbproc > 1), each process manages its individual usage. A value of 100 disable the limit. The default value is 100. Setting a lower value will prevent the compression work from slowing the whole process down and from introducing high latencies.

tune.comp.maxlevel <number>

Sets the maximum compression level. The compression level affects CPU usage during compression. Each session using compression initializes the compression algorithm with this value. The default is 1.

Compression restrictions

HAProxy Enterprise disables HTTP compression when:

  • The request does not advertise a supported compression algorithm in the Accept-Encoding header

  • The response message is HTTP/1.0

  • The HTTP status code is not 200, 201, 202 or 203

  • The response contains neither a Content-Length header nor a Transfer-Encoding header whose last value is chunked

  • The response contains a Content-Type header whose first value starts with multipart

  • The response contains a Cache-Control header with a value of no-transform

  • The response contains a Content-Encoding header, indicating that the response is already compressed (see compression offload)

  • The response contains an invalid ETag header or multiple Etag headers


Next up

Circuit Breaking