Forum Discussion

Andy_Herrman_22's avatar
Andy_Herrman_22
Icon for Nimbostratus rankNimbostratus
Jul 16, 2007

Local 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)?
application delivery
dev
devops
iRules

7 Replies

Sort By
  • David_Remington's avatar
    David_Remington
    Icon for Employee rankEmployee
    Jul 16, 2007
    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.
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Jul 18, 2007
    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_62629's avatar
    Mike_62629
    Icon for Nimbostratus rankNimbostratus
    May 19, 2008

    Posted 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_Menant's avatar
    Nicolas_Menant
    Icon for Employee rankEmployee
    May 19, 2008
    Hi,

     

     

    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
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    May 20, 2008
    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_62629's avatar
    Mike_62629
    Icon for Nimbostratus rankNimbostratus
    May 20, 2008
    Thanks, 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.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    May 21, 2008
    Hi Colin,

     

     

    Thanks for the info. If you find out more, let us know.

     

     

    Aaron