Using CPL with a CacheFlow appliance to identify problems with slow browsing
Sometimes routing or network issues can cause users to experience long delays or timeouts for certain destinations. Alternatively, some client subnets may experience congestion which has the same apparent effect on the user – slowness. Because the CacheFlow appliance handles large volumes of traffic, it can be hard to identify which transactions are affected, and thus hard to identify a pattern which might assist in diagnostics. This article provides a policy solution that can help identify patterns, by partitioning slow responses to a separate log.
Policy can be used on the CacheFlow appliance to identify patterns of slowness. The idea is to create an access-log facility which will receive slow responses only, which will allow them to be more easily identifiable among other traffic flowing through your appliance. Slow responses can be identified by the following criteria available in policy:
- total service time of the request in milliseconds
Filtering traffic simply on service time might seem like the most obvious solution, but high service times can be expected for large objects and are therefore not necessarily 'slow'. Using high service times in combination with the service bytes or service bitrate will yield much more accurate entries in the slow response time access-log.
Note: This policy cannot be applied via the Policy GUI. You will need to enter local policy – please see the CPL reference guide for general details.
Above criteria correspond to the following local CPL conditions, respectively:
Each of the policy conditions listed above follows the standard CPL numeric range syntax. The condition is true if the quantity falls in the range specified (inclusively). Either the left (lower) or the right (higher) boundary can be left out to indicate an open range. The use of suffixes 'K' (for 1000), 'M' (for 1,000,000) and 'G' (for 1,000,000,000) is supported.
1) Create a new access-log facility to log slow requests:
c) Log all requests that fail to achieve specified bitrates, where the bitrates are dependent on the total size:
Though each of the above examples can make sense depending on your circumstances, we recommend using b) as the one most generally applicable.
3) Tail the log using the https://<CFIP>:8082/Access-Log/tail-f/<log-name> URL on the appliance itself.
4) After transactions appear in the targeted log (‘slow_log’ in the above examples), you can proceed to try to determine what is common to them that is causing them to take a long time. Things to look for would be the common client, or a subnet of clients or a common destination.
Rate this Page
Please take a moment to complete this form to help us better serve you.