Forum Discussion

Luca_55898's avatar
Luca_55898
Icon for Nimbostratus rankNimbostratus
Aug 03, 2011

Possible performance issue with iRule?

Hi,

 

 

I have this iRule configured on a fairly standard HTTP VIP.

 

 

 

"when HTTP_REQUEST {

 

switch -glob [HTTP::uri] {

 

"/ee/employer*" { pool Pool_ee_employer_83 }

 

"/ee/search*" { pool Pool_ee_search_84 }

 

"/pack*" { pool Pool_pack_85 }

 

}

 

}"

 

 

The VIP does not have any persistance configured.

 

 

It has the default HTTP profile assigned

 

 

No default pool is selected either.

 

 

 

The iRule works fine, however people have been complaining that the images on the pages take a while to load and sometimes do not load at all.

 

When testing if i continually press refresh on my browser the images will load, but also the page changes its layout. For example - it goes from left aligned to centre aligned. Sometimes borders are displayed, sometimes they are not.

 

 

Could this be an issue with the iRule or the F5?

 

 

 

 

application delivery
dev
devops
iRules

12 Replies

Sort By
Show More
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Aug 04, 2011
    There have been issues in the past when requests should go to the default pool but don't. These are generally fixed when using a catch all class.

     

     

    I'm not sure what the latest is, but I always use a match all HTTP class when using HTTP classes. Here's an example of one issue (though it only occurs with WAM in use):

     

     

    sol10771: The BIG-IP system may send server-side HTTP requests to the wrong pool

     

    http://support.f5.com/kb/en-us/solutions/public/10000/700/sol10771.html

     

     

    Aaron
  • Kevin_Davies_40's avatar
    Kevin_Davies_40
    Icon for Nacreous rankNacreous
    Aug 04, 2011
    And that's the solution ID I couldnt find this morning, thanks Aaron. The problem occurs on LTM as well. The solution ID is not entirely correct, you don't have to be using one connect. Essentially HTTP classes are sticky so subsequent requests in the same TCP connection *regardless of URI* go to the same pool which is not what you would expect. The solution is to always implement a catch all HTTP class at the end to make sure non matching requests are sent to the correct pool.