Forum Discussion
Andy_Herrman_22
Nimbostratus
NimbostratusLocal var performance
Quick performance question. I'm looking back at the iRules I worked on a year ago for our F5 evaluation and noticed something odd. At the top of the iRule the URI and Host values are stored in variables, but later on the iRule looks up the values again.
For example:
when HTTP_REQUEST {
set fulluri [HTTP::uri]
set host [HTTP::host]
if { [HTTP::uri] starts_with "/servletPath" } {
set hcid [findstr [HTTP::uri] "?id=" 4 "&"]
}
}
Now, I vaguely remember this being done because I read that doing [HTTP::uri] was actually faster than doing the variable lookup, but this seems odd to me. Is there any truth to that, or should I change it to just use the variables I declared (and maybe submit my original code to the daily WTF)?
David_RemingtonEmployee
You read it here, probably:
http://devcentral.f5.com/wiki/default.aspx/iRules/HowToWriteFastRules.html
Pretty safe to assume it is still the case, imo.- The reason it's faster to us HTTP::uri later on is because this value is already cached. You're not performing another lookup, the data has been cached via TMM, and is available to the iRules interpreter as necessary. So all you're doing is pointing to that value in memory, not performing a lookup.
This means that setting your initial variables "fulluri" and "host" is not necessary. As a matter of fact, NOT setting them, and just using HTTP::uri and HTTP::host respectively is technically a performance gain.
HTH,
Colin 
Mike_62629Posted By Colin on 07/18/2007 2:50 PM
The reason it's faster to us HTTP::uri later on is because this value is already cached. You're not performing another lookup, the data has been cached via TMM, and is available to the iRules interpreter as necessary. So all you're doing is pointing to that value in memory, not performing a lookup.
This means that setting your initial variables "fulluri" and "host" is not necessary. As a matter of fact, NOT setting them, and just using HTTP::uri and HTTP::host respectively is technically a performance gain.
HTH,
Colin
Sorry to dredge up such an old thread, but I was wondering if this was also the case for other F5 internal vars, like
.[HTTP::cookie xyz]
Nicolas_MenantHi,
I think you should consider that this is the case globally.
If you have any doubt you should try the timing command to check the response for your interrogation
hoolioCirrostratus
A quick way to verify whether a command is cached or not is to log the current value, change it and then try to log it again. If the same value is logged the second time, then the command output is cached. This caching seems to only be maintained in the same event in the same priority. I think (almost?) all of the HTTP:: commands are cached. Maybe someone with definitive knowledge could add more detail (Click here)?when HTTP_REQUEST { log local0. "\[HTTP::uri\]: [HTTP::uri]" HTTP::uri "/modified" log local0. "\[HTTP::uri\]: [HTTP::uri]" log local0. "\[HTTP::cookie value test_cookie\]: [HTTP::cookie value test_cookie]" HTTP::cookie test_cookie "modified" log local0. "after modification: \[HTTP::cookie value test_cookie\]: [HTTP::cookie value test_cookie]" } when HTTP_REQUEST priority 501 { log local0. "priority 501 \[HTTP::uri\]: [HTTP::uri]" log local0. "priority 501 \[HTTP::cookie value test_cookie\]: [HTTP::cookie value test_cookie]" }
: [HTTP::uri]: /test
: after modification: [HTTP::uri]: /test
: [HTTP::cookie value test_cookie]: test_value
: after modification: [HTTP::cookie value test_cookie]: test_value
: priority 501 [HTTP::uri]: /modified
: priority 501 [HTTP::cookie value test_cookie]: modified
Aaron- Mike_62629Thanks, and Aaron that's a great tip. I didn't think to test like that, though I'm a bit suprized that modification doesn't update the cache. I imagine there could be several who run into that like a brick wall.
- hoolioHi Colin,
Thanks for the info. If you find out more, let us know.
Aaron