Time-based iRules

You could set your clock variables in the CLIENT_ACCEPTED event so they are only set once. If you are not using your uri variable, I wouldn't set it. If it is necessary, that variable will need to remain in the HTTP events.

There will be a performance hit for setting those variables each time, though I'm unsure if it would be noticeable. You can turn timing on to evaluate.

Details on how to configure it:

Posted By unRuleY on 3/22/2005 4:19 PM

That is a very good point. You have obviously thought about this. Of course, it will all really depend on just how often you expect to match. If it does not match often, then you are completely correct. If it matches regularly, then you would likely want to save the result in a variable. Another factor to weigh is the number of elements in the class/datagroup.

For those that are interested and paying attention, I'm now going to mention a YASF (yet another stealth feature):

You can enable timing statistics in a rule which will allow you to see just how many cycles are spent evaluating a given rule event. The way you do this is with the "timing on" statement.

An example that enables timing for all subsequent events in a rule is:

   
 rule my_fast_rule {   
    timing on   
    when HTTP_REQUEST {   
        Do some stuff   
    }   
 }   
 

An example of only timing a specific event is:

   
 rule my_slow_rule {   
    when HTTP_REQUEST timing on {   
        Do some other stuff   
    }   
 }   
 

This will then collect timing information each time the rule is evaluated and can be viewed with "b rule show all". You'll likely only want to look at the average and min numbers as max is often way, way out there due to the optimizations being performed on the first run of the rule. Additionally, enabling timing does have some overhead, though it should be negligible.

Details on how to make sense of the numbers:

http://devcentral.f5.com/Default.aspx?tabid=28&view=topic&forumid=5&postid=3650