Forum Discussion
Carl_Gottlieb_1
Nimbostratus
NimbostratusQueue 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
10 Replies
hoolioCirrostratus
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_1Cheers 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?
HamishCirrocumulus
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_1In 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.
- The RFE CR for counting session table entries is 61210.
- HamishHeh... But does anyone know when or if the CR might be implemented?
- hoolioNot 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 - hoolioHey 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
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
Employee
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
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
