Adding irules to vip that loop over DGL that are normally empty - ok practise ?

Question

Gurus&nbsp;
I have been doing a lot of work recently utilizing data group lists since they are simply awesome and I'm always trying to separate code from data.&nbsp;
I use them as simple arrays for listing strings or as hashes if I need key=value pairs.&nbsp;
Some examples I use dgl for are:&nbsp;
* Redirect "host" to "host.defaultdomain.com"&nbsp;
* Redirect "host1.defaultdomain.com" to "host.defaultdomain.com/defaultapp" by maintaining a "host1" := /defaultapp" key/value pair.&nbsp;
* Redirect host and/or uri to a new site optionally with fixed uri by maintaining "oldhost.domain.com := newhost.domain.com" and "olduri := newuri" key/value pairs.&nbsp;
* Turn on persistence cookie logging for debugging by adding a cookie name to a string dgl.&nbsp;
The idea is that nobody has to either edit iRules or even change iRule associations with VIPs - only edit data group lists. However, that of course only works if the VIP already&nbsp;
has all the necessary iRules associated with it - whether it's currently needed or not.&nbsp;
 &nbsp;
Example : log persistence cookies.&nbsp;
I have a dgl called "logged_persistence_cookies" which is usually empty. As standard part of any new HTTP VIP I use cookie persistence and name the persistence cookie uniquely after the app.&nbsp;
If I need to debug a persistence issue or need to know a certain host's stickieness details I simply add this app's persistence cookie's name to this dgl and it starts writing&nbsp;
persistence related info to the log. When done I remove the cookie name from the dgl again. Works perfectly !&nbsp;
 &nbsp;
My question is this:&nbsp;
The more of these dgl I add the more rules I need to add to every VIP. Most of the time most of the rules wind up doing nothing more than loop over empty data group lists so they effectively&nbsp;
do nothing but burn cpu cycles. Only the few times a year I add something to one of the dgl do they actually perform a useful task.&nbsp;
Is this bad practise ? Is looping over empty dgl cpu intensive ?&nbsp;
I really don't want anyone messing with irules or irule associations. I only want folks to maintain data group lists and it works very well from a functional perspective.&nbsp;
I'm just a bit concerned about all the empty looping going on most of the time.&nbsp;
Thoughts ?&nbsp;
 &nbsp;
 &nbsp;

nitass · Answer

this is my testing. i am running ve 10.2.4 hf4. 
  
  nothing in irule

root@ve10(Active)(tmos) list ltm rule myrule
ltm rule myrule {
    timing on
when HTTP_REQUEST {
}
}
root@ve10(Active)(tmos) show ltm rule myrule

Ltm::Rule Event: myrule:HTTP_REQUEST
------------------------------------
Priority                   500
Executions
  Total                  10.0K
  Failures                   0
  Aborts                     0
CPU Cycles on Executing
  Average                 3.3K
  Maximum                74.5K
  Minimum                 2.0K

empty data group

root@ve10(Active)(tmos) list ltm data-group logged_persistence_cookies
ltm data-group logged_persistence_cookies {
    type string
}
root@ve10(Active)(tmos) list ltm rule myrule
ltm rule myrule {
    timing on
when HTTP_REQUEST {
  foreach elm [class names logged_persistence_cookies] {
    if { [HTTP::cookie exists $elm] } {
       do something
       log local0. [HTTP::cookie $elm]
    }
  }
}
}
root@ve10(Active)(tmos) show ltm rule myrule

Ltm::Rule Event: myrule:HTTP_REQUEST
------------------------------------
Priority                    500
Executions
  Total                   10.0K
  Failures                    0
  Aborts                      0
CPU Cycles on Executing
  Average                 13.3K
  Maximum                412.7K
  Minimum                  7.9K

not-empty data group

root@ve10(Active)(tmos) list ltm data-group logged_persistence_cookies
ltm data-group logged_persistence_cookies {
    records {
        cookie1 { }
        cookie2 { }
        cookie3 { }
        tcookie { }
    }
    type string
}
root@ve10(Active)(tmos) list ltm rule myrule
ltm rule myrule {
    timing on
when HTTP_REQUEST {
  foreach elm [class names logged_persistence_cookies] {
    if { [HTTP::cookie exists $elm] } {
       do something
       log local0. [HTTP::cookie $elm]
    }
  }
}
}
root@ve10(Active)(tmos) show ltm rule myrule

Ltm::Rule Event: myrule:HTTP_REQUEST
------------------------------------
Priority                    500
Executions
  Total                   10.0K
  Failures                    0
  Aborts                      0
CPU Cycles on Executing
  Average                126.8K
  Maximum                564.1K
  Minimum                 66.2K

stucky101_88485 · Answer

Nitass 
&nbsp; Sorry I should have phrased my question better. I'm not looking to eval the performance of the irule itself. Obviously, looping over a dgl with actual content will burn up more cycles than an empty one. 
&nbsp; What I'm looking for is the difference on the virtual server side between executing an irule that essentially does nothing but examine a dgl (to find that it's empty) and not executing the irule in the first place. 
&nbsp; Most of my vs have the following 5 standard irules: 
&nbsp;  
&nbsp; filter_http_methods  
&nbsp; short_to_fqdn_https  
&nbsp; filter_ciphers  
&nbsp; redirect_uri_https  
&nbsp; log_persistence_cookie 
&nbsp; check_maintenance  
&nbsp;  
&nbsp; The first 3 rules loop over dgl that always have content. The last 2 irules, however, loop over dgl that are normally empty since on a regular day I don't need to debug persistence nor is the app in maintenance mode. 
&nbsp; I'm wondering if this vs would burn significantly less cycles if I removed the last 2 irules. The only stats I can find for a vs are 5sec/1min/5min min load average but that's all 0% so  would not see a difference. 
&nbsp;  
&nbsp; I guess the real question is : How many cpu cycles does a virtual server burn when it execs an irule that looks at an empty dgl ?  
&nbsp; I assume the actual "looping" process never really starts since the group has nothing to loop over so I'm probably worrying over nothing but I wanted to check anyway. 
&nbsp; I'm simply worried that executing an irule alone burns more cpu cycles than I'd like. 
&nbsp;  
&nbsp; I hope this is clearer. 
&nbsp; Thx

nitass · Answer

i thought i understood what you were asking. anyway, i got 0% cpu usage ratio on virtual server same as you. that is the reason i used irule timing instead. actually, what i wanted to say is the different between average cpu cycles on execution of nothing in irule and of empty data group case is about 10K (13.3K - 3.3K) in my testing.

stucky101_88485 · Answer

So in other words my extra 2 irules at the end of each vs cost roughly 20k cycles of overhead per vs. 
&nbsp; Question is - is this significant enough to worry. 
&nbsp; I'm at about 10% cpu utilisation on this ltm.

nitass · Answer

So in other words my extra 2 irules at the end of each vs cost roughly 20k cycles of overhead per vs. i think you had better re-test on your unit. 
&nbsp;  
&nbsp; Question is - is this significant enough to worry.my cpu clock speed is 2,666,761,000 cycles per second (2666.761 MHz). so, based on irules runtime calculator, it takes 0.000374987% cpu utilization per request. 
&nbsp;  
&nbsp; irule timing: how to convert Cycles to Seconds 
&nbsp; https://devcentral.f5.com/community/group/aft/23451/asg/50 
&nbsp;  
&nbsp; irules runtime calculator 
&nbsp; https://devcentral.f5.com/downloads/techtips/F5DevCentral_iRulesRuntimeCalculator.zip

Forum Discussion

Adding irules to vip that loop over DGL that are normally empty - ok practise ?

6 Replies

Recent Discussions

import live updates from version x to version y

Tenant image upgrade

iRule editor partition button does not work

F5Access | MacOS Sonoma

Overwriting or adding LTM SSL Traffic cert and key using iControlREST

Related Content

Getting Started with BIG-IP Next: Adding Instances to Central Manager

adding pool members in cli

Multiple AD Authentication

ASM - Adding Allowed URL's via CLI in 2023

Yubikey Authentication Modes and Azure AD integration via the APM