Page load performance with a Cisco ACE4710
The ACE has two different ways of treating the L7 connections internally, that we call “proxied” and “unproxied”. In essence, the proxied mode means that the traffic will be processed by one of the CPU (normally to inspect/modify the L7 data), while, on the unproxied mode, the ACE sets up a hardware shortcut (Fastpath) that allows forwarding traffic without the need to do any processing on it.
For a L7 connection, the ACE will proxy it at the beginning, and, once all the L7 processing has been done it will unproxy the connection to save resources until L7 processing is required again. Before it goes ahead with the unproxying, it needs to see the ACK for the last L7 data sent.
In packet captures, we see that the client is taking approximately 200ms to send this acknowledgement each time. When a connection is composed of many HTTP requests, the proxy/unproxy process can add up a total delay of several seconds.
The configuration of a sorry/backup server farm with for example a HTTP redirect to a sorry page will cause the ACE to treat the connections to the VIP as a L7 and influence the total page load time.
The proxy/unproxy delay can have a big impact for situations in which the client is taking a long time to send the acknowledgement, so, the ACE allows to change the behavior. It is possible to define a “round-trip-time” threshold so that connections from clients with a RTT value higher than the threshold are never unproxied.
You can do this by setting the threshold to 0 to ensure to keep connections always proxied. To do this, you would need to configure a parameter map like the one below and add it to the policy-map.
parameter-map type connection
set tcp wan-optimization rtt 0
Even though this setting will most likely solve the issue, it also has some drawbacks. The main one is that the ACE appliance only supports up to 256K simultaneous L7 connections in proxied state (which includes also the connections towards the servers, so, it would be 128K for client connections), so, if the amount of simultaneous connections reaches that limit, new connections would be dropped. The second issue, although not so impacting, would be that the maximum number of connections per second supported would also go down slightly due to the increased processing needed.