Forum Discussion
iRule performs 100x slower under load
Hello,
I have an iRule (BIGIP v9.4.8) whose HTTP_REQUEST timing performance drops by 100x when under load. How can I diagnose what's happening? Under what conditions can an iRule slow down (in terms of cycles/request) when there's more significant traffic (200-1000 HTTP requests per second)?
HTTP_REQUEST performance in a development environment (BIG IP 3400 w/ v9.4.8) ran with timing stats of roughly 1,000,000 cycles/request average and 10,000,000 cycles/request max. By commenting out pieces of code, we found that 90% of that time is spent on decrypting cookies. According to the "F5DevCentral_iRulesRuntimeCalculator" (see "Evaluating iRule Performance") the 10^6 cycles only represent 357 microseconds. No big deal. The max of 10^7 is a little worry but is still only 3.5 milliseconds.
"b rule show all" output from developer environment (BIG IP v9.4.8, BIG IP 3400)
+-> HTTP_REQUEST 7252 total 0 fail 0 abort
| | Cycles (min, avg, max) = (46052, 838937, 9343832)
+-> HTTP_RESPONSE 7079 total 0 fail 0 abort
| | Cycles (min, avg, max) = (34872, 849654, 9031528)
When we deploy this rule into production (BIG IP v9.4.8, BIG IP 3400), the performance falls off a cliff:
+-> HTTP_REQUEST 4530 total 2 fail 0 abort
| | Cycles (min, avg, max) = (239321, 103.3M, 200.0M)
+-> HTTP_RESPONSE 4406 total 8 fail 0 abort
| | Cycles (min, avg, max) = (390987, 132.1M, 197.9M)
(Note: the 7252 requests in DEV were from an entire day of testing where the 4530 requests in prod came from only a couple of minutes.)
We've done fairly comprehensive comparisons between dev and production and I don't see any significant configuration differences. The CPU is about 30% busy. The memory (through 'top') is running at 50% (of 2GB). This box, like the dev box, serves a large of virtual servers but under greater load.
I've gone through the "Ten Steps to iRules Optimization" and the "Evaluating iRule Performance" documents linked to from here: SOL11769. However, I haven't yet found info that would explain the timing behavior differences between dev and prod.
From other posts on DEVCENTRAL, I've found the 'tmctl' and 'b memory' commands to see if I have a memory leak.
Commenting out sections of the iRule step by step in the development environment, reseting statistics and re-exercising the rule, I can account for all of the "cycles" seen in the DEV environment. But there is a 100x slow down when the rule is facing heavier traffic in production. What tricks do you know to figure out why?
Thanks for your time,
-- Chris
21 Replies
- hoolio
Cirrostratus
Glad to hear that. I'll send the email I'd started yesterday now :)
Aaron - Colin_Walker_12Historic F5 AccountWow, that's a massive change! I'll see about writing something up to outline this massive difference. Thanks for the info!
Colin - hoolio
Cirrostratus
Hey Colin,
You can check C576042-1 for details on this.
Aaron - Colin_Walker_12Historic F5 AccountWill do.
Colin - spark_86682Historic F5 AccountPlease don't use AES::encrypt for cookie data. I know it's much faster, but it 1) doesn't decrypt across TMMs, and 2) doesn't decrypt across failover/reboot events. If you're not running in CMP mode (and it sounds like the OP isn't) then 1 won't matter, but 2 still might. This is tracked as issue 224113. Sorry for the bad news.
- spark_86682Historic F5 AccountOne little bit of possible good news is that reportedly the slowness problem is limited to the iRule command, and that you might see a performance increase if you can configure cookie encryption in the HTTP profile itself. I haven't tested this myself, but that's what I'm told.
- hoolio
Cirrostratus
Hi Chris,
Sorry for giving a bad recommendation. I didn't know about the AES::encrypt issue that Spark pointed out. I think the HTTP profile option to encrypt cookies should work for your scenario.
It would be great if you could open a case with F5 Support and request to be added to the AES::encrypt bug ID, 224113. This will help raise the visibility of the issue internally.
Thanks, Aaron - Chris_Huston_16
Nimbostratus
Hi Spark,
Would the two problems still be an issue if the AES key isn't reset on each RULE_INIT call?
Hoolio: no sweat man - it made good sense and is the same style as the "Encrypt Cookies" iRule template in the F5 editor.
We're doing another production test on Thursday. Hope to have more information then.
-- Chris - spark_86682Historic F5 AccountWould the two problems still be an issue if the AES key isn't reset on each RULE_INIT call?
Yes, it's an issue inherent in the AES::encrypt/decrypt calls, regardless of keying. - hoolio
Cirrostratus
The AES key issue was fixed in 11.2:
sol12944: The AES::decrypt iRule command does not work across TMM or after a failover or reboot
https://support.f5.com/kb/en-us/solutions/public/12000/900/sol12944.html
Aaron
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com