vADC Docs

HowTo: Log slow connections in Stingray Traffic Manager

by on ‎02-24-2013 07:16 AM - edited on ‎06-01-2015 03:37 PM by PaulWallace (2,600 Views)

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

connection.data.set("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 = connection.data.get("start");

$now = sys.time.highres();

$diff = ($now - $start);



if ( $diff > $THRESHOLD ) {

     $uri = http.getRawURL();

     $node = connection.getNode();

     log.info ("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

 

Comments
by cgibson
on ‎03-05-2013 05:52 PM

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?

by
on ‎03-08-2013 09:33 AM

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 connection.data.set 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.

by cgibson
on ‎03-08-2013 09:50 AM

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? 

by
on ‎03-08-2013 09:55 AM

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.

by cgibson
on ‎03-08-2013 09:58 AM

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? 

by
on ‎03-08-2013 10:00 AM

Yep - that's correct.

by cgibson
on ‎03-13-2013 07:09 AM

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?

by
on ‎03-13-2013 10:49 AM

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 

Contributors