Showing results for 
Search instead for 
Did you mean: 

Tuning Recommendations for using the Traffic Manager with Apache Backends

The Virtual Traffic Manager is often used as an application delivery controller which passes HTTP traffic to backend nodes using the Apache HTTP Server. This guide aims to provide some general advice on tuning such a deployment.

Virtual Server Configuration


A virtual server passing traffic to Apache backends can use a number of protocols including HTTP, Generic client first and SSL (if the website uses HTTPS). Of all these protocols HTTP (with SSL Decryption enabled if HTTPS is used) will provide the best experience:

  • Backend connections can be reused for different frontend connections.
  • The traffic manager's builtin webcache can be used to cache static content to decrease latency and reduce backend load.
  • The traffic manager can offer the HTTP/2 protocol on frontend connections even if the Apache version on the backends doesn't support it.
  • TrafficScripts rules can inspect and change HTTP headers in both directions.


Backend Connection Management

Traffic Manager

The Traffic Manager offers two important per pool settings for controlling the connections to backend nodes:

  • The configuration key max_connections_pernode controls how many concurrent connections will be created by a single traffic manager to a single backend node. Please note that the limit is enforced per single traffic manager and not for the whole in a cluster. In a clustered deployment the number of concurrent connections scale up with the the number of traffic managers using a backend node at the same time in an active active setup.
    Depending on the maximum number of concurrent connections that a single Apache instance can handle it can be advisable to adjust this setting accordingly to prevent overloading the backend nodes. Please refer to Apache Performance Tuning for more information on tuning Apache's connection limits.
  • The configuration key max_idle_connections_pernode controls how many idle connections to a single backend the traffic manager will keep open. Keeping idle connections open will speed up handling further requests but will consume slightly more resources on the backends. For websites which handle a large number of concurrent, short lived HTTP requests increasing the number of allowed idle connections can reduce request latency and thereby improve performance.


By default Apache closes idle keep-alive connections after 5 seconds while the Traffic Manager will try to reuse them for up to 10 seconds (controlled by the global configuration key idle_connection_timeout). This can cause retries or even request failures when the Traffic Manager tries to reuse a connection at the exact moment when Apache decides to close it. To avoid this it is advisable to change Apache's timeout via the KeepAliveTimeout configuration directive to at least five second higher than the traffic manager's timeout.

SSL Configuration


The Apache HTTP Server offers multiple loaded modules to add support for HTTPS. The most popular is mod_ssl which uses the OpenSSL TLS stack.


Using SSL Encryption on a pool configured on the traffic manager should work with the combination of Apache and mod_ssl without any specific tuning. The following adjustments might however help to improve performance.

Traffic Manager

  • Ensure the the client side SSL cache of the traffic manager is enabled. This cache will make sure that most SSL connections to the backend nodes use SSL session resumption which is considerably faster and consumes less CPU power on both the traffic manager and the backend node. The client cache is controlled via the ssl!client_cache!enabled config key and enabled by default.
  • Ensure the the client side SSL cache of the traffic manager is size appropriately. It should be at least as large as the total of distinct nodes that the traffic managers connects to, across all pools, via SSL. The size can be adjusted using the config key ssl!client_cache!size which defaults to 1024.
  • Ensure that TLS 1.2 is enabled and a ciphers based on AES_128_GCM_SHA256 (for example SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256) are enabled and preferred. These ciphers combine security with excellent performance, in particular on CPUs which support the AES-NI and AVX instruction sets.


In the unlikely case that the Traffic Manager SSL settings suggested above cause connection failures changing the mod_ssl configuration as suggested below should fix the problems:


SSLCipherSuite HIGH
SSLProtocol all -SSLv3

The SSL session cache is also disabled in the Apache HTTP server by default although Linux distributions often enabled it in the distributed configuration file. Please refer to the documentation of the SSLSessionCache configuration directive for information how to enable and size the session cache.


For optimal performance is also advisable to use a Linux distribution which ships version 2.4 or newer of the Apache HTTP server and OpenSSL version 1.0.2 or newer (for example Debian 9 or newer or Ubuntu 16.04 or newer).


Version history
Revision #:
10 of 10
Last update:
‎05-15-2018 05:36:AM
Updated by: