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 ProxySG 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 ProxySG 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 - total size of the client transaction in bytes - the effective bitrate of the client transaction, in bits per second
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.
Examples: - client.service.time=2000.. ; true for any request that takes 2 seconds or more to process - client.service.time=2K.. ; same as the above, using a handy abbreviation - client.service.bytes=50M.. ; true for any request that involves 50 Megabytes or more of client-side data transfer. - client.service.bytes=50M..100M ; true for any request between 50 and 100 Megabytes of data transfer (but not more or less) - client.service.effective_bitrate=56K..1M ; true for any request where the total data transfer (client.service.bytes) divided by the total service time (client.service.time) is between 56 Kbps and 1Mbps.
1) Create a new access-log facility to log slow requests:
2) Use the available gestures to log slow transactions to the newly created access logs. There are three ways to do this: a) Log all requests that take more than 60 seconds to complete in an attempt to identify timeouts:
c) Log all requests that fail to achieve specified bitrates, where the bitrates are dependent on the total size: - at least 50Kbps for objects up to 20KB - at least 100Kbps for objects 20KB to 100KB - at least 300Kbps for larger objects
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.
Imported Document ID: 000014457
Subscribing will provide email updates when this Article is updated. Login is required.