Too many HTTP requests too fast

[Tommy Rampal]

Hey again all,

So pretty much my GUI actively does HTTP requests and waits for the body upon a user interacting with it. That's fine, until I noticed something..

For testing purposes, I just hammered through my own built menus/interfaces to get to what I wanted to test to (I've made my own 'panel' system that checks for server variable changes when a panel is changed), I noticed that I managed to crash my script my clicking too fast: "Too many HTTP requests too fast. (Set HTTP_VERBOSE_THROTTLE, FALSE in the parameters to hide these messages.)"

Luckily I have implemented a time-out on my scripts for when a user abandons the GUI without finishing appropiately, or a HTTP failure (e.g. my web server is down). But for users who know where they want to be with the GUI, or those in a rush, this can be quite an inconvenience.

Has anyone else worked with this problem and/or does anyone have any advice for a practical work around? Sorry if this is an easy fix, I'm just about to head to bed and thought it'd be quicker if I wake up to a solution tomorrow ;)

[Acheron Gloom]

The specific throttle is 25 requests per 25 seconds. You could do, for example, 25 requests in a second but then you would have to wait another 24 seconds. Or you could do 1 per second for the 25 seconds.

The throttle is per-object, so no it wouldn't be a very easy fix.

You can either:

A. Just make sure there aren't too many requests, and if so throttle it yourself.

B. Redo the way your system works.

C. Use some sort of rezzed proxy.

[Tommy Rampal]

Option A sounds like the most appealing to me. I think it's because there was some flawed passage where too many panel changes occured per each click. I can tell it to not do as many server checks, as I'm sure it'd survive without them.

For future reference, how would one throttle requests? Is that just as simple as adding a script sleeper?

[Void Singer]

it should really depend on your methods.

in general you can force it not to accept new triggers while an old one is waiting to complete, and add in a small sleep to ensure that happens. another way would be to queue request internally while you are still waiting on a response from the previous, and send those as a complex message once the previous clears... you could even combine the methods.

[Qie Niangao]

I'm not sure how elaborate a mechanism is warranted by this application -- a second-long sleep may be good enough -- but to avoid hitting the system throttle and still be able to issue short bursts of requests, there's some non-trivial bookkeeping involved.  It's especially non-trivial if your script has other timer-based processing, asynchronous with the HTTP requests.

Although I've not used this feature of the llHTTPRequest() call, it does return NULL_KEY if it hits the throttle, so in theory you could just put it in a sleep-retry loop whenever that condition obtains.  I think, however, when it hits the throttle, it does something undesirable in a product... probably it complains on DEBUG_CHANNEL or something.

[Tommy Rampal]

Yeah, well everytime it sends a HTTP request, it triggers a 'Connecting to server' display and disables all user interactivity until it receives the body and handles the data accordingly. It saves the request as a string so it knows how to deal which body is returned, so if the requestid == NULL_KEY, I can literally tell it to wait 1-2 seconds, destroy the token and try the request again.

I got the message in the error/debug window (viewer 2), it didn't kill the script; it timed out and reverted back to the welcome screen as I expected.

Does anyone know if there's a way to turn off the 'Too many requests too fast' warning (to not confuse non-technical minded users). And does anyone have any statistics on exactly how quick it takes to reach the HTTP throttle; and if it temporarily halts/sleeps HTTP requests for a further amount of time once the throttle has been reached (so I should add a mandatory sleep)?

Thanks again guys.

[Void Singer]

---

Tommy Rampal wrote:

Does anyone know if there's a way to turn off the 'Too many requests too fast' warning (to not confuse non-technical minded users). And does anyone have any statistics on exactly how quick it takes to reach the HTTP throttle; and if it temporarily halts/sleeps HTTP requests for a further amount of time once the throttle has been reached (so I should add a mandatory sleep)?

Thanks again guys.

---

25 in 20sec is the max burst speed, 1/sec is the sustained rate....  the linked threads have a bit more detail, once throttled it takes ~40sec to clear, and throttled requests (even though they're discarded) will count against limits. Kelly recommended spacing them by 5sec

ETA:

I wouldn't worry about things that only show up in ths script error window as users generally turn that off, but if you set verbose to false messages are suppressed too.