Forum Discussion
Chris_Miller
Altostratus
AltostratusA Great Read - "Comparing iRule Control Statements"
I'm not sure how often everyone in this forum checks out tech tips, but this new one by Joe is very cool.
http://devcentral.f5.com/Tutorials/...ments.aspx
It illustrates the different results you'll see using if/else, switch, switch -glob, and class with different list sizes.
He expands upon the "Ten Steps to iRules Optimization" tech tip, primarily the "Understand Control Statements" section.
http://devcentral.f5.com/Tutorials/...ation.aspx
From my experience, it's very easy to write if/else statements but they're obviously not the best for performance. Switch statements are easy to write, relatively easy to read, and perform very well. I find the class command to be the most interesting. Sometimes, lists are simply unavoidable due to quantity but for less than 10 items, a lot of users might use a switch statement instead. Personally, I use datagroups constantly because I like my iRules to be as short and easy-to-read as possible. Sure, this means having to look at several small datagroups to understand the functionality of a rule with which you're not familiar, but it's still been my favorite. I've found the "-value" option of "class search" to be extremely powerful as well.
What do you guys prefer and why?
- Chris_MillerI was also surprised to see -glob cause slower processing. Any reason for that?
- Thanks Chris, it was a fun article to come up with and write. I love writing full applications within iRules!
As for the "-glob" adding processing, I would assume that to be the case but I didn't expect it to add on nearly 10% overhead for non-wildcard comparisons. I guess I should add in "-regexp" to see how much more that adds as well. Lesson, if you aren't using wildcards and want to use switch, make sure -glob isn't present. It'll save you a good chunk of CPU.
-Joe - Chris_MillerPosted By Joe on 01/12/2011 08:40 PM
Thanks Chris, it was a fun article to come up with and write. I love writing full applications within iRules!
As for the "-glob" adding processing, I would assume that to be the case but I didn't expect it to add on nearly 10% overhead for non-wildcard comparisons. I guess I should add in "-regexp" to see how much more that adds as well. Lesson, if you aren't using wildcards and want to use switch, make sure -glob isn't present. It'll save you a good chunk of CPU.
-Joe
Whenever someone has asked for a switch statement, I've always tacked on -glob just in case they did wildcards later. Given that hit, I might have to re-evaluate that. - Chris_MillerOne other awesome takeaway was your recommendation to use a stats profile to make sure your if/elses were ordered as efficiently as possible.
Order your if/elseif's with most frequent hits at the top. If/elseif's must perform the full comparison for each if and elseif. If you can move the most frequently hit match to the top, you'll have much less processing overhead. If you don't know which hits are the highest, think about creating a Statistics profile to dynamically store your hit counts and then modify you iRule accordingly.
For some wacky reason, I hadn't thought of doing that and have basically been guessing at customer behavior. Thanks for that one too! - Oh yeah, forgot about that one! Since that article was posted, we introduced the new table command with it's support of subtables. If you have LTM 10.1 or greater, I would suggesting using the optimized access to the session table with subtables.
-Joe
