Forum Discussion

ranshe_75308's avatar
ranshe_75308
Icon for Nimbostratus rankNimbostratus
Oct 13, 2011

URI based persistence with limitations (NB)

Hi,

 

I have a pool of servers delivering content, and I'd like to set persistence based on URI.

 

My fear is, however, that if I have a big "hit" (e.g. new piece of content lots of folks are after), persistence will actually hurt me since all these requests will hammer one particular server.

 

So is it possible to build a rule that would also look @ amount of calls to a specific server and will NOT use persistence after some threshold is hit?

 

 

Or perhaps this is a built-in feature of F5?

 

(Sorry, I'm a noob.)

 

 

Thanks!

 

  • c_p_i_o_17707's avatar
    c_p_i_o_17707
    Historic F5 Account
    To answer your 2nd question first, AFAIK, this is not a current built-in feature in the BIG-IP.

     

     

    If it OK for a request to go to a different server during heavy load, then why do you need persistence? Clearly if the content available on different servers is equal, then persistence is not necessary.

     

     

    You didn't mention what sort of persistence you are using and that may make a difference to the answer.

     

    Figuring out the amount of calls to a specific server at a given time is tricky business - especially given the fact that most new platforms have more than one TMM running on the box.

     

    I could see using the "table" command to keep counters and increment/decrement them appropriately.

     

    Now, when the amount connections to a particular pool member reaches an appropriate threshold, you can do a "persist delete" (if using source persistence - for example) or do a HTTP::header delete (if using cookie persistence). This is followed by a LB::reselect to select a different pool member. Of course you now have to add protections to prevent the other pool members from getting saturated.

     

    As you can see, this iRule may start getting complex fast.

     

     

    Another solution you may want to consider is the use of "priority groups" on pool members in conjunction with "connection limits". There is a pool member setting that lets you control what to do with "persist connections" if a pool member is already at the configured limit.