Link to Online Topic Content
Effect of iRules on Performance
This is a classic case of “It Depends”. Since iRules are written individually to solve specific issues or do specific functions necessary for a particular scenario, there is not a fixed sheet of performance numbers showing how an iRule will impact performance.
iRules do get compiled into byte code, and can run at wire speed, but it really depends on what you're doing. Many times there is more than one way to write an iRule and one method may work more efficiently than another.
That said there are ways to see how an iRule is performing by collecting and interpreting runtime statistics by inserting a timing command into event declarations to see over all CPU usage when under load. This tool will help you to create an iRule that is performing the best on your system.
Collecting Statistics
To generate & collect runtime statistics, you can insert the command "timing on" into your iRule. When you run traffic through your iRule with timing enabled, LTM will keep track of how many CPU cycles are spent evaluating each iRule event. You can enable rule timing for the entire iRule, or only for specific events.
To enable timing for the entire iRule, insert the "timing on" command at the top of the rule before the first "when EVENT_NAME" clause.
With the timing command in place, each time the rule is evaluated, LTM will collect the timing information for the requested events.
To get a decent average for each of the events, you'll want to run at least a couple thousand iterations of the iRule under the anticipated production load.
Viewing Statistics
The statistics for your iRule (as measured in CPU cycles) may be viewed at the command line or console by running
The output includes totals for executions, failures & aborts along with minimum, average & maximum cycles consumed for each event since stats were last cleared.
--- Ltm::Rule rule_name
--- Executions
Total 729 Failures 0 Aborts 0 CPU Cycles on Executing Average 3959 Maximum 53936 Minimum 3693
Evaluating statistics
“Average cycles reported” is the most useful metric of real-world performance, assuming a large representative load sample was evaluated.
The “maximum cycles reported” is often very large since it includes some one-time and periodic system overhead. (More on that below.)
Here's a spreadsheet (iRules Runtime Calculator) that will calculate percentage of CPU load per iteration once you populate it with your clock speed and the statistics gathered with the "timing" command. (Clock speed can be found by running 'cat /proc/cpuinfo' at the command line.)
Caveats
Timing is intended to be used only as an optimization/debug tool, and does have a small impact on performance; so don't leave it turned on indefinitely.
Timing functionality seems to exhibit a 70 - 100 cycle margin of error.
Use average cycles for most analyses. Maximum cycles is not always an accurate indicator of actual iRule performance, as the very first call a newly edited iRule includes the cycles consumed for compile-time optimizations, which will be reflected in an
inflated maximum cycles value. The simple solution to this is to wait until the first time the rule is hit, then reset the statistics.
However, maximum cycles is also somewhat inflated by OS scheduling overhead incurred at least once per tick, so the max value is often overstated even if stats are cleared after compilation.
Link to Online Topic Content
Global Variable Impact
iRules use global variables to make variable data that is created in one context, that is available to other connections, virtual servers, and Traffic Management Microkernel (TMM) instances. If a virtual server references an iRule that uses a global variable that is not Clustered Multiprocessing (CMP) compatible, the virtual server will be ineligible for CMP processing. In most cases, it is good to retain the benefits of CMP processing when using iRules. This document expands on the various ways to represent global variable data, making it available to other connections, other virtual servers, and other TMM instances.
In many cases, variable data used in an iRule is required to be available only within the scope of the current connection. The use of Tcl local variables satisfies this
requirement, and does not affect CMP compatibility.
In other cases, variable data must be available globally, that is, outside the context of a connection. The most common requirement people have is to capture data from one connection, then to reference that data from subsequent connections that are part of the same session. This requirement can be further refined to include both multiple connections traversing the same TMM instance, such as would be seen on a non-CMP-enabled system or virtual server, and also multiple related connections on CMP-non-CMP-enabled virtual servers, which may traverse different TMM instances.
Another common use for global variables is to share data among multiple iRules that run on the same BIG-IP system. For example, to set and enforce a cumulative concurrent connection limit, an iRule would need to both set a globally accessible limit value, and also allow each iRule instance to update a separate globally-accessible counter value.
The use of global variables can force the BIG-IP system to automatically disable CMP processing, which is known as demotion. Demotion of a virtual server limits processing of that virtual server to only one CPU core. This can adversely affect performance on multi-core BIG-IP systems, as only a fraction of the available CPU resources are available for each demoted virtual server. In addition, CMP demotion can create an internal
communication bottleneck for virtual servers that are WebAccelerator-enabled or ASM-enabled.
The following sections explain each of three popular methods for sharing iRules-derived data globally, including the CMP compatibility of each method.
Using Tcl global variables
Tcl global variables are not actually global on a CMP-enabled BIG-IP system, since the global variables are not shared among TMM instances. Tcl global variables are accessible globally only within the local TMM instance (meaning that each TMM instance would need to set and update separately its own copy of the variable and the value of the variable). As a result, the TMM process running on one processor is not able to access the contents of the same Tcl global variable that was set by a different TMM process, even if both TMM processes are handling connections for the same virtual server. Because of this limitation, the use of a Tcl global variable in an iRule automatically demotes from CMP any virtual server to which it is applied. This avoids the confusion that would otherwise result from accessing and updating multiple
instances of the same “global” variable. Because the virtual server will be automatically demoted from CMP, you should restrict the use of Tcl global variables to iRules that will be applied to virtual servers that do not depend on CMP processing.
Using static global variables
If you must share static data (data that will never be modified by the iRule itself) across CMP-enabled virtual servers, you can use a static global variable. A static global variable stores data globally to the entire BIG-IP system, and is set within each TMM instance each time the iRule is initialized. The value of a static global variable is assumed not to change unless the iRule is re-initialized. As a result, static global variables must be set within the RULE_INIT event. Static global variables set within the RULE_INIT event are propagated to all TMM instances each time the iRule is initialized: when the iRule is loaded at system startup, when the configuration is re-loaded, or when the iRule is modified from within the BIG-IP Configuration utility and saved.
Important: While it is possible to use the set command to modify a static global variable within the iRule and outside of the RULE_INIT event, such modifications will not be propagated to each TMM instance; they will be visible to only the TMM process on which the modification was made, resulting in inconsistent values for the static global variable across TMM instances. As a result, F5 strongly recommends that you do not update the value of any static global variable within the iRule.
Using the session table to store global variables
If you must share non-static global data across CMP-enabled virtual servers, you can use the session table to store and reference the data. Session table data is shared among all TMM instances. Using the session table imposes considerable operational overhead, but the preservation of CMP processing for the virtual server typically far outweighs any such impact.
You can use the table command to manipulate the session table. For details, refer to the DevCentral article linked in the Supplemental Information section below.
Recommendations
As you can see, there are several different options for using global variables, or the equivalent functionality, in session tables. Each of these options has advantages and disadvantages in their use. Typically these decisions are made on performance and ease of implementation.
In summary:
Tcl global variables
You should restrict the use of Tcl global variables to iRules that will be applied to virtual servers that do not depend on CMP processing.
Static global variables
The use of static global variables is recommended for sharing static data (data that will not be updated by any iRule) among TMM instances that are used by CMP-enabled virtual servers, or for sharing static data among multiple iRules without affecting the CMP status of any virtual server to which it is applied.
Session table
The use of the session table is recommended for sharing dynamic global variable data (data that will be updated within the iRule) among CMP-enabled virtual servers.