help optimize iRule

At the application layer, I'd suggest you consider using RAM caching to handle static content instead of bypassing ASM. On a conceptual level, RAM cache + ASM provides good security in that the first request for static content is validated by ASM before being sent to the pool. Once the pool member responds, LTM caches the response content in memory and then answers subsequent requests for the same content from cache. You should see good decreases in both ASM resource utilization as well as load on the static content servers. You may even have an existing amount of RAM Cache licensed, depending on which platform and version you are using. You can check with your account manager for details on this.

 

 

If you do decide to bypass ASM for static content, in 9.4.2 - 9.4.8, you should use PLUGIN::disable ASM and PLUGIN::enable ASM. Make sure to explicitly enable ASM in the iRule in the else clause where you're disabling it. Failing to do so means ASM will be bypassed if a client makes a request for a static object and then makes subsequent requests for non-static objects afterward on the same TCP connection. You can check SOL7616 for details on how to bypass ASM from an iRule:

 

 

SOL7616: Configuring static web content to bypass the BIG-IP ASM

 

https://support.f5.com/kb/en-us/solutions/public/7000/600/sol7616.html

 

 

You didn't mention which ASM version you are running. If you're on a version lower than 9.4.2, you should see a significant jump in performance by upgrading to 9.4.8. In 9.4.2 and higher, separate TCP connections between TMM and ASM were replaced with an API. This change has resulting in good size increases in performance.

 

 

As for gauging CPU usage, 50% sounds a lot like you're checking top output from the command line and seeing 0% CPU0 usage and 100% TMM CPU usage being averaged to 50%. You can check SOL3242 for details:

 

 

 

BIG-IP versions 9.4 through 9.4.8 licensed for ASM or WebAccelerator

 

https://support.f5.com/kb/en-us/solutions/public/3000/200/sol3242.html

 

 

When a multi-processor system is licensed for BIG-IP ASM or BIG-IP WebAccelerator, even if the platform is CMP-capable, CMP is automatically disabled. TMM will be assigned to the highest numbered CPU, and the remaining processors will be utilized by the host operating system and the BIG-IP ASM or WebAccelerator processes. This behavior will be apparent when using the top command, as TMM will only be running on one CPU, and that CPU will display 100 percent usage. The Configuration utility will display the correct separate CPU and TMM usage.

 

 

 

 

Aaron