How To Write Fast Rules

Summary: Some helpful tips on writing fast iRules.
The following Rules To Live By have been helpful in making faster iRules, and there are likely many more. Please contribute to make this guide more accurate and complete.

First:

Make sure you check out the Tech Tip by Joe going over some of the DC Team’s iRules Optimization materials It’s hugely helpful when trying to write fast iRules and keep your cycles down.

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. $static::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 any more on a given connection.
11) The rules timing functionality seems to have between 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)
12) The information on tcl speed applies to allowed iRules commands, see http://wiki.tcl.tk/11885 . Write expr commands with the argument in curly braces whenever possible. This avoids conversion of numbers in strings and back. The speed impact may be a factor of 20 or so.

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.