I see this examples like this all over the place: when HTTP_REQUEST { if { [HTTP::host] equals "www.myhost.com" and [HTTP::uri] equals "/myuri" } { HTTP::redirect https://[HTTP::host][HTTP::uri] } } I am going though a large number of iRules in an attempt to optimize, and I had a thought occur to me while looking at one of mine like this. Shouldn't I be able to consolidate these two conditions into one, and wouldn't it be more efficient? Something like this? when HTTP_REQUEST { if { [[HTTP::host][HTTP::uri]] equals "www.myhost.com/myuri" } { HTTP::redirect https://[HTTP::host][HTTP::uri] } } As a practical matter, this iRule generates an error when it is triggered:TCL error: www.myhost.com - invalid command name "www.myhost.com/myuri" while executing "[HTTP::host][HTTP::uri]" Assuming I can figure out how to properly write this condition (please help???), wouldn't this be more efficient than writing two conditions to evaluate and then compare? If I can get the syntax right, I'll test it out.

Edit - I see what you're saying here...basically, combining http::host and http::uri into one command...I'll look into. Looking at the http command list below...I don't see an option here: http://devcentral.f5.com/wiki/default.aspx/iRules.HTTP

Hi SMP, It certainly would seem efficient. You can't do this now within iRules because they are 2 seperate functions in a single if conditional statement. Perhaps another method would be setting the entire URL into a variable then doing the IF comparison. i.E. when HTTP_REQUEST { set url [HTTP::host][HTTP::uri] if {$::url equals "www.something.com/blah"} { . . . do something . . . } } Doesn't seem efficient because you end up creating a variable, but it looks cleaner on the IF statement, at least to me. I hope this helps Bhattman

The error is coming up because you are surrounding the combined string with brackets. Try replacing the surrounding brackets with quotes (or curly braces if your embedded string contains quotes itself) when HTTP_REQUEST { if { "[HTTP::host][HTTP::uri]" equals "www.myhost.com/myuri" } { HTTP::redirect https://[HTTP::host][HTTP::uri] } } I'd be interested in the performance gain with this approach. While the first example does do two string comparisons, they are both operating on the builtin variables which are essentially a memory lookup (ie. no additional memory allocations required) while the combined approach takes those two memory lookups and has to allocated a new temporary string and then do the same number of character comparisons but with the overhead of the memory allocation. On first guess, I would think this would actually be slower, but would love to see the results. As Colin and I say in our optimization presentations, it's a fine line when optimizing your code. You can go hog wild and make your code the absolute fastest it can be but if it's harder to read and limits maintainability, then the trade-off of a few clock cycles, in most cases, will not be worth it. In my opinion the combined approach is more concise and easier to read and thus would be preferable. But that's just my opinion... -Joe

I guess I learned something new. Bhattman

Thank you very much for weighing in on this Joe, adding double-quotes did indeed consolidate the conditions as I expected. Boy, TCL sure isn't Perl is it? Since you were kind enough to provide valueable insight, I did some analysis. I used ApacheBench Version 2.0.41-dev <$Revision: 1.141 $>. I hit the VIP 100000 times with a maximum number of concurrent connections set to 25. And I ran the test three times for each method. The results are below. Assuming my methodology is sound, it looks to me like the most effecient in terms of processing cycles is to consolidate the conditions likeif { "[HTTP::host][HTTP::uri]" equals "www.myhost.com/admin" } The difference is small, but evident. Also, I wonder why the min-cycles is always zero??? I'm running 10.2.0. timing on when HTTP_REQUEST { if { "[HTTP::host][HTTP::uri]" equals "www.myhost.com/admin" } { HTTP::uri "/new_uri" } } ******************** ltm rule-event myrule:HTTP_REQUEST { aborts 0 avg-cycles 11501 event-type HTTP_REQUEST failures 0 max-cycles 121243 min-cycles 0 name myrule priority 500 total-executions 100022 } ltm rule-event myrule:HTTP_REQUEST { aborts 0 avg-cycles 11536 event-type HTTP_REQUEST failures 0 max-cycles 220940 min-cycles 0 name myrule priority 500 total-executions 100016 } ltm rule-event myrule:HTTP_REQUEST { aborts 0 avg-cycles 11366 event-type HTTP_REQUEST failures 0 max-cycles 105512 min-cycles 0 name myrule priority 500 total-executions 100015 } timing on when HTTP_REQUEST { if { [HTTP::host] equals "www.myhost.com" and [HTTP::uri] equals "/admin" } { HTTP::uri "/new_uri" } } ******************** ltm rule-event myrule:HTTP_REQUEST { aborts 0 avg-cycles 11877 event-type HTTP_REQUEST failures 0 max-cycles 112904 min-cycles 0 name myrule priority 500 total-executions 100015 } ltm rule-event myrule:HTTP_REQUEST { aborts 0 avg-cycles 11751 event-type HTTP_REQUEST failures 0 max-cycles 148691 min-cycles 0 name myrule priority 500 total-executions 100018 } ltm rule-event myrule:HTTP_REQUEST { aborts 0 avg-cycles 11810 event-type HTTP_REQUEST failures 0 max-cycles 77001 min-cycles 0 name myrule priority 500 total-executions 100014 }

Optimizing If statement conditions

14 Replies

Joe_Pruitt
Jun 24, 2010
Another optimization technique that is often forgotten is to omit all code that always succeeds. If, for instance, the host on the virtual is always www.myhost.com (the virtual isn't multi-hosting domains), then leaving that check out completely wouldn't be a bad idea. In this case, it would be faster to build multiple iRules to run with different virtuals, than building a single iRule you could apply to mutliple virtuals. It would be more to maintain, but it would be faster.

Good point for Jason on the "string tolower" checks. That is almost always done on the URI but isn't needed on the host header.

-Joe

smp_86112

Cirrostratus

Jun 28, 2010

Yes, both Jason and hoolio bring up points I didn't consider. It seems this consolidation idea is only useful in pretty limited circumstances. Here are the results of my testing when forcing the string to lowercase (sorry for the long delay). It seems that adding the string tolower statement reversed the results. Does that make sense to you?


timing on
when HTTP_REQUEST {
  if { [string tolower [HTTP::host][HTTP::uri]] equals "www.myhost.com/admin" } {
    HTTP::uri "/new_uri"
  }
}
ltm rule-event  {
    aborts 0
    avg-cycles 14762
    event-type HTTP_REQUEST
    failures 0
    max-cycles 146684
    min-cycles 0
    name www.myhost.com
    priority 500
    total-executions 100017
}
ltm rule-event  {
    aborts 0
    avg-cycles 14892
    event-type HTTP_REQUEST
    failures 0
    max-cycles 121975
    min-cycles 0
    name www.myhost.com
    priority 500
    total-executions 100010
}
ltm rule-event  {
    aborts 0
    avg-cycles 14804
    event-type HTTP_REQUEST
    failures 0
    max-cycles 160099
    min-cycles 0
    name www.myhost.com
    priority 500
    total-executions 100014
}
 
timing on
when HTTP_REQUEST {
  if { [HTTP::host] equals "www.myhost.com" and [string tolower [HTTP::uri]] equals "/admin" } {
    HTTP::uri "/new_uri"
  }
}
ltm rule-event  {
    aborts 0
    avg-cycles 14466
    event-type HTTP_REQUEST
    failures 0
    max-cycles 89955
    min-cycles 0
    name www.myhost.com
    priority 500
    total-executions 100014
}
ltm rule-event  {
    aborts 0
    avg-cycles 14457
    event-type HTTP_REQUEST
    failures 0
    max-cycles 129122
    min-cycles 0
    name www.myhost.com
    priority 500
    total-executions 100020
}
ltm rule-event  {
    aborts 0
    avg-cycles 14129
    event-type HTTP_REQUEST
    failures 0
    max-cycles 156109
    min-cycles 0
    name www.myhost.com
    priority 500
    total-executions 100021
}

hoolio
Cirrostratus
Jun 28, 2010
I think that's just down to the extra few cycles it takes to handle a longer string that's being set to lower case:

% set str ABCDEFGHIJKLMNOPQRSTABCDEFGHIJKLMN...

% string length $str

1000

% time {string tolower $str} 1000

79 microseconds per iteration

% set smaller_str [string range $str 100 end]

% time {string tolower $smaller_str} 1000

65 microseconds per iteration/

Though in theory you should set the Host value to lower case in order to check it. RFC2616 states that the Host evaluation must be done case-insensitively. In practice, I think all major browsers set the host to lowercase before sending the request anyhow.

Aaron

smp_86112

Cirrostratus

Jun 28, 2010

You are absolutely right hoolio. I did the test again, this time setting the strings to lowercase in both conditions. It seems the consolidated statement is still faster, and the difference is a bit wider in this case. I won't post the whole thing anymore, just the avg-cycles:


timing on
when HTTP_REQUEST {
  if { [string tolower [HTTP::host][HTTP::uri]] equals "www.myhost.com/admin" } {
    HTTP::uri "/new_uri"
  }
}
avg-cycles 14762
avg-cycles 14892
avg-cycles 14804


timing on
when HTTP_REQUEST {
  if { [string tolower [HTTP::host]] equals "www.myhost.com" and [string tolower [HTTP::uri]] equals "/admin" } {
    HTTP::uri "/new_uri"
  }
}
avg-cycles 16219
avg-cycles 16526
avg-cycles 16626

Forum Discussion

Optimizing If statement conditions

14 Replies

F5 Academy at AppWorld 2026

Aswin MK - November 2025 Featured Member

Introducing the F5 AI Assistant for BIG-IP

Recent Discussions

F5 XC 503 upstream_reset_before_response_started{protocol_error}

CVE mitigation on F5 XC vs classic F5 WAF

F5 mssql health monitor failing

Could not communicate with the system. Try to reload page.

UCS Encryption Question

Related Content

S3 Traffic Optimization with F5 BIG-IP & NetApp StorageGRID

Conditional XOR operations

Solution for Citrix Optimal Gateway Routing

Quick Optimizations for F5 BIG-IP Virtual Edition

Intermediate iRules: Nested Conditionals

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS