How to write fast iRules: suggestions from my own experience

 

I don't know if anyone from F5 agrees, but I suggest the following Rules To Live By for helping to make iRules fast. I'm sure there are many more... I hope others will contribute to make this more accurate and complete.

 

 

Good luck!

 

 

 

 

Rules To Live By:

 

1) It's better to use chained "if"/"elseif" statements than to use separate "if" statements (likely due to "if"/"elseif" being a single statement so fewer commands are lookup up and run, and fewer return values must be considered).

 

 

2) It's better to use "switch" than any form of "if", whenever possible (likely due to the added expression evaluation in "if")

 

 

3) It's better to use "switch" (even with -glob) instead of "matchclass" for comparisons of 100 elements or less (and of course only if your data does not need to be dynamic); (this is likely due to matchclass using md5 as it's hash)

 

 

4) It's better to use a directly-indexed array (i.e. $::my_array(my_index) ) than to use switch or matchclass (again, assuming your data doesn't need to be dynamic); (this is likely because matchclass requires calling a function, and includes additional matching features that cost CPU cycles)

 

 

5) It's better to use a command like [HTTP::uri] than to place the value in a variable (tested up to 20 re-uses, it did not seem to be converging -- variables appear to always be more expensive). (this is likely due optimization which caches the result of commands in case they are re-used)

 

 

6) The amount of code in an unused switch statement or an un-called if block doesn't seem to be a performance consideration. Only worry about what code is executed.

 

 

7) Consider what data you're using (whether it's string, numeric, or binary), and consider how you're using it while keeping in mind what values would have to be converted. i.e. Compare numbers to numbers, strings to strings, and binary to binary -- be mindful of implicit conversions that TCL might do (including "==" vs "eq", and using quoting).

 

 

8) Be creative when trying to solve your problem. Consider "scan" and "binary" instead of "string".

 

 

9) Try to solve your problem with the smallest number of functions possible. For example, try using a single "scan" instead of multiple "string" commands.

 

 

10) Consider using the "event" command to disable events that aren't needed anymore on a given connection.

 

 

11) The rules timing functionality seems to have beteween a 70 and 100 cycle margin of error (and of course the very first call to the rule takes a very long time to compile the rule which inflates the max value)

 

 

 

a1l0s2k9