If your goal is to simply check the server's response time to a request, I'm including a small snippet of what I have done in the past.
Probably the best time to capture the actual response time is between HTTP_REQUEST_SEND and HTTP_RESPONSE.
ltm profile statistics DELAY_STAT {
field1 total
field2 webtest_total
field3 webtest_slow
field4 webtest_fast
}
ltm rule LOG-Delay {
when RULE_INIT {
what is a slow response in milliseconds
set static::slow_response 2000
}
when HTTP_REQUEST_SEND {
STATS::incr DELAY_STAT total
clientside {
if {[string tolower [HTTP::host]] contains "onpoint342labupgrade2013"} {
STATS::incr DELAY_STAT webtest_total
set URL [string tolower [HTTP::host]][HTTP::uri]
set SENT [clock clicks -milliseconds]
}
}
}
when HTTP_RESPONE {
exit event if variable is not set
if {![info exists SENT]} { return }
set TIME [expr {[clock clicks -milliseconds] - $SENT}]
if {$TIME >= $static::slow_response} {
STATS::incr DELAY_STAT webtest_slow
log local0. "[HTTP::status]: Client [IP::client_addr]; \
Server [IP::server_addr]:[TCP::server_port]; URL ${URL}; Time ${TIME}ms"
} else {
STATS::incr DELAY_STAT webtest_fast
}
unset SENT URL TIME
}
}
As long as HTTP pipelining is not being used, and hopefully it's not, this would be fine.
Notes
- If you expect a lot of logging, I recommend using HSL instead of the log command.
- I'm not logging every bit of information, you can add as needed.
- You should check out the request logging profile on the F5. It may be able to accomplish what you are looking for without an iRule, though I don't think you can control which URLs it is logging.
- I added STATS to track all/slow/fast requests. You would need to add the stats profile to the virtual server for it to work. In the past, I have found it handy to see how many requests were fast vs slow at a glance. Additional STATS fields can be added fairly easily to track other things without requiring you to sift through log messages.
- The delay between HTTP_REQUEST_SEND and HTTP_RESPONSE may not include the total response time. The HTTP_RESPONSE event fires when the F5 has received the complete HTTP header, which is not always the same as the response contents.