Showing results for 
Search instead for 
Did you mean: 

HowTo: Log slow connections in Stingray Traffic Manager

Request rule


The request rule below captures the start time for each request and sets a connection data value called “start” for each request:-


$tm = sys.time.highres();

# Don't store $tm directly, use sprintf to preserve precision"start", string.sprintf( "%f", $tm ) );


Response rule


The following response rule then tests each response against a threshold, which is currently set to 6 seconds. A log entry is written to the event log for each response that takes longer to complete than the 6 second threshold. Each log entry will show the response time in seconds, the back-end node used and the full URI of the request:


$THRESHOLD = 6;   # Response time in (integer) seconds above

                  # which requests are logged.

$start ="start");

$now = sys.time.highres();

$diff = ($now - $start);

if ( $diff > $THRESHOLD ) {

     $uri = http.getRawURL();

     $node = connection.getNode(); ("SLOW REQUEST (" . $diff . "s) " . $node . ":" . $uri );



The information in the event log will be useful to identify patterns in slow connections. For example, it might be that all log entries relate to RSS connections, indicating that there might be a problem with the RSS content.


Read more


Version history
Revision #:
1 of 1
Last update:
‎02-24-2013 07:16:AM
Updated by:
Labels (1)

I made a copy of this script and applied it to my virtual server but I'm I'm not getting any entries in my log.  Are there any prerequisite changes that I need to make before it starts working?

There was a subtle bug in the script above which I've now corrected.  I think that this was causing your problem.

Internally, when we store floating point numbers using or data.set, we use the %g sprintf format string, and this can cause loss of precision, particularly with highres time numbers.  The modification above uses %f to format the value before we store it to preserve precision and give you an accurate result.

Thanks!  When I implement this do I need to place all of the code in one script and apply it as request rule or do I need to create separate request and response rules? 

You'll need two rules. 

The request rule is triggered when the request is received - it's the first snippet in the article above. It gets the current time and stores it with the connection. If possible, this should be one of the first request rules that is run (you can change the order in the virtual server->rules edit page)

The response rule is triggered when the traffic manager starts processing a response.  It's the second snippet in the article above; it gets the current time and compares with the stored time (when the request was received).  If possible, make this one of the last response rules that are run.

Great, I'll give it a try and report back.  We currently have the Zeus enforcer rule as our only response rule, if I remember correctly this rule should always be the last one applied right? 

Yep - that's correct.

When I implemented this in our test environment I just placed the request rule section of the script at the end of the request rule that I already had in place for that particular site.  If I want to put this in place for a select number of sites (each site has its own rule) that share the same virtual server would I have to declare a different variable (%f) for each site? What would I have to do on the response rule end?  Would each site need its own?

This pair of request and response rules will instrument every request* that is processed by the virtual server.  If you manage traffic for several sites using a single Stingray virtual server, all of the requests will be instrumented, so you should not need to edit the rule.

* Not strictly every request - if you use http.redirect or http.sendResponse in the request rule, or if Stingray responds from cache, or if the request times out, then Stingray will not run the response rules against that transaction