Forum Discussion

Carl_Gottlieb_1's avatar
Carl_Gottlieb_1
Icon for Nimbostratus rankNimbostratus
Jun 18, 2008

Queue traffic after session rate limit reached

Hi Guys,

 

 

I have a website where the login systems can't cope with a massive ramp up of traffic, e.g. 10,000 users trying to login in the space of 2 minutes.

 

 

Any idea if this is possible:

 

 

1) The number of ‘logins per minute’ should be parameterised

 

2) Once the ‘logins per minute’ value is reached additional logins should be queued for a ‘n’ number of seconds. Users should not be redirected to another page. Instead their request will just queue on the BigIP and appear like a very slow login submission.

 

3) If a login request is still in the queue after ‘n’ number of seconds it will be redirected to a sorry page.

 

 

I see from codeshare that 1) and 3) are possible, but would need some performance testing. My concern is how 2) is achieved and if queueing individual requests is possible on the BigIP.

 

 

Thanks in advance for any thoughts,

 

 

cheers

 

Carl

 

application delivery
dev
devops
iRules

10 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jun 18, 2008
    Hey Carl,

     

     

    Queueing connections doesn't seem to be practical:

     

     

     

    http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=2149321872

     

     

    Is it possible to write an iRule that has a wait time of 25 seconds before proceeding to the next step?

     

     

    Spark: No, it's not possible to do this. iRule execution is single-threaded, so if you did somehow pause execution (like run a tight wait-loop as someone suggested), then you would be holding up all other packet processing. The multiple watchdogs on the LTM would notice this, and take appropriate action (restart tmm, or failover, or reboot, or some combination thereof). So you don't want to do that. Could you explain what you're really wanting to do? Perhaps we can find some different way of accomplishing it.

     

     

     

     

    Perhaps you could use a rate class or use javascript to instruct the client to re-request after x number of seconds without keeping the connection to the VIP open?

     

     

    Anyone have other suggestions?

     

     

    Aaron
  • Carl_Gottlieb_1's avatar
    Carl_Gottlieb_1
    Icon for Nimbostratus rankNimbostratus
    Jun 18, 2008
    Cheers Aaron,

     

     

    I can safely say we can't propose any changes to the application, so any kind of mechanism would have to be on the BigIP. I'm guessing that responding with a javascript piece of code asking for a retry such as a meta-refresh would have to be heavily tested against the range of browsers, but at least it moves the "queuing" to the client's browser.

     

     

    Would introducing rate shaping potentially cause a bottle neck on the BigIP with a danger of flooding the memory with masses of inbound connections?
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Jun 18, 2008
    You could externalise the session creation to a separate website... Then limit there. The session website can be responsible for counting & creating/verifying/expiring sessions... Include something in the session cookie so the F5 can tell when a session is expired (Or needs checking for expiration)...

     

     

    Then when your'e out of sessions, the session service can simply return an auto-refreshing webpage that says sorry we're busy I'll try again in XX seconds...

     

     

    (The external webiste for sessions is necessary because you can't count the number of sessions in a session table yet on F5 - I think from memory there is a CR requesting this though).

     

     

    Hamish.

     

  • Carl_Gottlieb_1's avatar
    Carl_Gottlieb_1
    Icon for Nimbostratus rankNimbostratus
    Jun 18, 2008
    In my view that's one of the most elegant ways of resolving the issue. I think that's how Ticketmaster works when it gets busy. Unfortunately due to timescales we have no capacity for web page dev work so I'm back to focusing on purely iRule / LTM functionality.
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Jul 31, 2008
    Heh... But does anyone know when or if the CR might be implemented?
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jul 31, 2008
    Not any time soon...

     

     

    From F5 Support:

     

     

    There is no accurate ETA on this request. The CR is currently in the 9.x enhancement queue and will be revisited in a future release some time next year. The subcase has been attached to the CR as requested.

     

     

     

     

    More cases would raise the visibility though.

     

     

    Aaron
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Sep 17, 2009
    Hey Spark,

     

     

    Was CR61210 ever implemented? Is there a way to get a count of the session table entries in v10? I don't remember seeing anything about it lately.

     

     

    Thanks,

     

    Aaron
  • supertoaster2_8's avatar
    supertoaster2_8
    Icon for Nimbostratus rankNimbostratus
    Aug 08, 2013

    Do we have the link were we can rate-limit the connection if it is reached show a sorry page...saying too many connection try again later?

     

  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Aug 09, 2013
    Do we have the link were we can rate-limit the connection if it is reached show a sorry page...saying too many connection try again later?is this helpful?

     

     

    iRule::ology - Table Based Rate Limiting by Colin Walker

     

    https://devcentral.f5.com/tech-tips/articles/iruleology-table-based-rate-limiting.UgSE4W0-ZQI