Forum Discussion

Carol_Williams_'s avatar
Carol_Williams_
Icon for Nimbostratus rankNimbostratus
Oct 28, 2009

help optimize iRule

Could someone please help me. I have a redirect iRule that is slow. I need to make sure all images are 1 not going through my httpclass profile and 2 if they are coming from a list of BOTs going to my botpot. The iRule I have works but is slow when the site is under a load.

 

 

 

when HTTP_REQUEST {

 

if { [matchclass [HTTP::uri] ends_with ::images] } {

 

if { [matchclass [HTTP::header User-Agent] contains ::robots] } {

 

pool MyBotPool

 

} else {

 

pool MyImagePool

 

}

 

HTTP::class disable

 

}

 

}

 

 

 

Thank You

 

 

Carol Williams

 

 

7 Replies

  • Hi Carol,

    For your iRule...

     
     when HTTP_REQUEST { 
        if { [matchclass [HTTP::uri] ends_with ::images] } { 
           if { [matchclass [HTTP::header User-Agent] contains ::robots] } { 
              pool MyBotPool 
           } else { 
              pool MyImagePool 
        } 
        HTTP::class disable 
        } 
     } 
     

    ...the HTTP class selection is being disabled on every request. Is this what you intended?

    Can you clarify what you are trying to use an HTTP class for? Also, which LTM version are you running?

    When you say the iRule is slow under load, can you provide more detail? How are you quantifying the slowness? Is the slowness occurring for all requests from all User-Agents--or just specific clients or specific requests?

    Are you seeing high TMM CPU utilization in tmstat output or the performance graphs? Do you think it's an LTM resource issue?

    Aaron
  • Sorry, I had the indentations on your iRule wrong. The HTTP::class disable command is only being run for image requests:

     
     when HTTP_REQUEST { 
        if { [matchclass [HTTP::uri] ends_with ::images] } { 
           if { [matchclass [HTTP::header User-Agent] contains ::robots] } { 
              pool MyBotPool 
           } else { 
              pool MyImagePool 
           } 
           HTTP::class disable 
        } 
     } 
     

    Aaron
  • Aaron,

     

    Thank you for your quick response. The httpclass is used to send requests through ASM, we do not want to do this if the request is an image. The slowness isn't on the LTM but on responsiveness on the website. With the rule in we are get about 600MB of traffic with a 10 second overall response time. We normally see a response time of 4-5 seconds. The CPU on the LTM maintains at around 50% idle the entire time so it isn't a resource issue.

     

    Thanks again for your help

     

    Carol Williams
  • Carol: This may or not help, but one thing to keep an eye out for in cases like this is SNAT pool exhaustion if you're using snat on this virtual server. It'll show itself as random delays which affect overall performance (or worse in some cases).

     

     

    If you're using a snat pool consider increasing the size to eliminate this as a potential issue. If you're using automap, definitely try using a pool with several addresses in it. 600MB is a non-trivial amount of traffic at L7 so I could see this as a potential issue if you're using SNAT here.

     

     

    -Matt
  • 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
  • Aaron, you are one amazing talent, and a wonderful cornerstone to this community.

     

     

    Just an FYI, beginning in 10.0.1, the syntax for affecting the plugin status is ASM::enable/ASM::disable.
  • Aaron,

     

    To answer a couple of your questions. The LTMs are version 9.4.4 and the ASMs are version 10.0.1. The iRule is on the LTM. We use httpclass profiles to determine where the traffic is suppose to go. We do not have RamCache enabled.

     

     

    Carol Williams