Queue traffic after session rate limit reached

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

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?

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.

 

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.

The RFE CR for counting session table entries is 61210.

Heh... But does anyone know when or if the CR might be implemented?

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

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

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