Accepted Solutions
Hello Samuel-
Subsequent connecitons will not be compressed once you hit the limit - they will just go to the server through the rule as if compression were not enabled on it.
The documentation located in the optimization guidelines explains what happens for optimized connections and notes that compressed traffic is handled separately. Unfortunately, we nicely avoid mentioning what action is taken on compressed traffic in the compression guide. Even though the hardware chip that handles compression is different than the chip that handles optimization, they both have the same result when hitting max connections by going into a pass through state. If you hit 1000 connections, the second that one of the connections ends (via a FIN or RST), the next new session that hits a rule with compression enabled will be compressed.
Here is the link for the optimization guidelines:
Specifically this note about what we do for the optimization engine:
Note 
Application acceleration performance on the ACE is 50 to 100 Mbps throughput. With typical page sizes and browser usage patterns, this equates to roughly 1,000 concurrent connections. Subsequent connections bypass the application acceleration engine. This limitation applies only to traffic that is explicitly configured to receive application acceleration processing (for example, FlashForward, Delta Optimization). Traffic that is not configured to receive application acceleration processing is not subject to these limitations. Also, because the ACE HTTP compression is implemented separately in hardware, it is not subject to these limitations. For example, if you have a mix of application-accelerated and non-application-accelerated traffic, the former is limited; the latter is not. If you have 50 Mbps of application-accelerated traffic, the ACE can still deliver up to 1.9 Gbps throughput for the non-application-accelerated traffic.
Regards,
Chris
Hello Samuel-
Subsequent connecitons will not be compressed once you hit the limit - they will just go to the server through the rule as if compression were not enabled on it.
The documentation located in the optimization guidelines explains what happens for optimized connections and notes that compressed traffic is handled separately. Unfortunately, we nicely avoid mentioning what action is taken on compressed traffic in the compression guide. Even though the hardware chip that handles compression is different than the chip that handles optimization, they both have the same result when hitting max connections by going into a pass through state. If you hit 1000 connections, the second that one of the connections ends (via a FIN or RST), the next new session that hits a rule with compression enabled will be compressed.
Here is the link for the optimization guidelines:
Specifically this note about what we do for the optimization engine:
Note Application acceleration performance on the ACE is 50 to 100 Mbps throughput. With typical page sizes and browser usage patterns, this equates to roughly 1,000 concurrent connections. Subsequent connections bypass the application acceleration engine. This limitation applies only to traffic that is explicitly configured to receive application acceleration processing (for example, FlashForward, Delta Optimization). Traffic that is not configured to receive application acceleration processing is not subject to these limitations. Also, because the ACE HTTP compression is implemented separately in hardware, it is not subject to these limitations. For example, if you have a mix of application-accelerated and non-application-accelerated traffic, the former is limited; the latter is not. If you have 50 Mbps of application-accelerated traffic, the ACE can still deliver up to 1.9 Gbps throughput for the non-application-accelerated traffic.
Regards,
Chris
