While it is improbable that the
if { $static::debug } { ... }
construct is chewing up tons of CPU, you should absolutely remove those statements for production use. Either comment them out, or remove them completely (some advocate using a simple iApp to choose whether to include them or not, then in the iApp logic purge the statements, most easily accomplished if they are on a single line). To illustrate, the timing value after 100 executions for the following rule:
when CLIENT_ACCEPTED {
return
}
is as follows:
---------------------------------------------
Ltm::Rule Event: comment-test:CLIENT_ACCEPTED
---------------------------------------------
Priority 500
Executions
Total 100
Failures 0
Aborts 0
CPU Cycles on Executing
Average 12.1K
Maximum 44.2K
Minimum 6.2K
On the other hand, for the following:
when RULE_INIT {
set static::ldebug 0
}
when CLIENT_ACCEPTED {
if { $static::ldebug } { log local0. "Log Entry 01" }
if { $static::ldebug } { log local0. "Log Entry 02" }
if { $static::ldebug } { log local0. "Log Entry 03" }
if { $static::ldebug } { log local0. "Log Entry 04" }
if { $static::ldebug } { log local0. "Log Entry 05" }
if { $static::ldebug } { log local0. "Log Entry 06" }
if { $static::ldebug } { log local0. "Log Entry 07" }
if { $static::ldebug } { log local0. "Log Entry 08" }
if { $static::ldebug } { log local0. "Log Entry 09" }
if { $static::ldebug } { log local0. "Log Entry 10" }
if { $static::ldebug } { log local0. "Log Entry 11" }
if { $static::ldebug } { log local0. "Log Entry 12" }
if { $static::ldebug } { log local0. "Log Entry 13" }
if { $static::ldebug } { log local0. "Log Entry 14" }
if { $static::ldebug } { log local0. "Log Entry 15" }
if { $static::ldebug } { log local0. "Log Entry 16" }
if { $static::ldebug } { log local0. "Log Entry 17" }
if { $static::ldebug } { log local0. "Log Entry 18" }
if { $static::ldebug } { log local0. "Log Entry 19" }
if { $static::ldebug } { log local0. "Log Entry 20" }
return
}
the timing result it:
---------------------------------------------
Ltm::Rule Event: comment-test:CLIENT_ACCEPTED
---------------------------------------------
Priority 500
Executions
Total 100
Failures 0
Aborts 0
CPU Cycles on Executing
Average 31.7K
Maximum 96.3K
Minimum 20.9K
Now ~20k extra cycles is definitely not a deal-breaker, but it doesn't help, and that's 20k extra cycles per connection. I'll also say that this value scales linearly, with cycle consumption proportional to the number of these you have (so, if I double it to 40 instances, the average climbs to 49k).
As an aside, I strongly advocate engaging F5 Professional Services to analyze your rule and help optimize. As a bonus, the rule will be archived by F5 Support, and will receive full support from that point onward.