Hi Fernando,
Which ASM version are you running (b version)? And which platform are you running ASM on (b platform | head)?
I expect that the increased load is due to ASM--not the iRule. For 9.x, ASM processes (mainly bd and mysqld) run on CPU0 and TMM runs on CPU1. And iRules run within TMM. So if you're seeing low CPU1 usage, it means the iRule is not the major concern. You might be able to optimize the iRule slightly with a switch statement and using getfield instead of findstr, but the existing version should be fine.
Now all this configuration is applied and it works, but the performance of CPUs is very high (CPU0: 80%, CPU1: 100%, AVERAGE: 90%). The main overhead is being introduced by ASM (we can see in ASM CPU Graphs), but it is only a 40 % of CPU0.
In 9.x, TMM doesn't provide reporting to the Linux host on how many cycles its using. So top and ps will show TMM using 50% of both CPUs (and 100% of CPU1). The performance graphs in the GUI or tmstat from the CLI will show more accurate usage for TMM.
Which processes on CPU0 are using the majority of the CPU cycles? Is it bd, mysql or learning_manager.pl? If it's bd or mysql, then there is cause for concern. learning_manager.pl is set to a lower CPU priority so it will give up cycles as standard priority processes require them.
How many HTTP requests per second did you have going through ASM or the unit in total while the BD CPU graph was showing ~60% load?
Aaron