SL 1.12.1 - http throttle improved!

Hey guys, seen this? Second Life Release 1.12.1 notes

The throttle on llHTTPRequest seems to be getting relaxed, I'm just not 100% sure what to? 1 second per object or 1 second per all owners objects per sim?


What's everyone else's opinion?

Hate those multi-facetted sentences - much like double negatives.

Means the originator can come back in a weeks time and say "oops - my bad - what I meant to say was....."

Once per object per owner per sim - implies to me that if you own 10 objects in a sim you can send 10 per second.

Means that the email and IM throttle bypass methods will work - create a tonne of objects.

( Although Curious if they mean 1 per "complete object" - IE whole link set - or once per prim " )

I wonder if they really meant to say: 1 time per second, per owner, per sim. (leaving out the "per object".

That would mean if you had 7 objects in one sim, they are limited overall to 1 time per second (meaning each object could only use the command, on average, 1 time every 7 seconds). But, if you had 50 objects, each in their own sim, spread around the SL world, then they would be unhindered by one another and that they could each use that command 1 time per second.

As I understand it, the new llHTTPRequest throttle is a limit of 1 http request per object per sim.

So, if you have 500 prims in a sim each making http requests, your limit is 500 a second.

If you have 16,000 prims in a sim each making http requests, your limit is 16,000 a second.

If you have 4 prims linked together to be one object, your limit is one per second (as you only have one object).

If you have 500 4-prim objects your limit is 500 per second not 20,000 (4x500) as you have 500 objects.

If you have one prim containing 200 scripts that all make http requests, your limit is one http request per second (as you still only have one prim).

Many thanks to the dev team for pushing this through!

So Torley's reply indicates one per second per owner per sim, which is still a heck of a lot better than the current limits. I thought once per object sounded a bit radical, so I believe this is probably right.

Hold on...

Did I miss a bit - what reply from Torley ?

And the Blog link says "once per second per object per sim"

Once per second per owner is good - but is hardly radical - just means they have fixed the current rotating bucket thing ( or whatever they call it ) and moved the limit to 60 per minute per owner - still not enough to use effectively if you own an island and would like to use http all over it.

But mustnt complain too much - step in the right direction and all that.

Torley's reply (in the Comments of the Linden Blog) says one per second per owner per sim. That makes sense.

However, the release notes listed in the Blog have been edited to say "once per second per object per sim". This does not make sense as the "per sim" part would seem to be redundant if one assumes that an object can exist in only one sim at a time or does not change sims more often than once a second.

It is not clear which is correct. I guess programmers will find out after the update goes live.

I would read "once per second per object per sim" as

1. Each sim measures the rate and does not check the other sims.
2. Each linked set "object" can send one message per second.

Yes the per sim is redundant, but I suspect it is adding up the "User per sim" rate for posible other throttles.

Edit: I saw torley's message, and we will just have to wait and test it to see how it really performs.

You know, I just had a thought.

This may actually be worse than the current system in some cases, such as when your processing is in bursts.

Currently, you could send 20 requests in 1 second, as long as you then wait out the timer window before doing anymore. With a 1 sec/object limit, you'll have to be more concious of response times between requests.

The wiki doesn't mention anything about script delay on the current command, so we may need to all add a llSleep(1.0) after every llHTTPRequest, to ensure no lost requests (when doing mutiple requests at once or on a non-predicatble schedule that is).

Just did some testing in the current preview grid (1.12.1 (0)). All tests were done many times in Sandbox Goguen, with one other person on the other side of the sim, and the sim doing less than 1000 IPS and Time Dilation at 1.00. In other words a very good sim.

When sending one request per second, there was no errors, the script was able to continue forever.

When sending one every 0.75 seconds, SL gave a "Too many HTTP requests too fast." error after around 37 requests, and with 0.5 seconds at 25 requests. After the error, that prim could not send any more requests for about a minute or so.

Notice I said prim, not object. The limit is per prim. Another object, or even another linked prim, could continue sending requests, but the one that generated the error could not.

Next test was bursts. I put llHTTPRequest() inside a loop to see how many could be done at once. SL allowed 25 before giving the error.

I tried sending 20 requests every 20 seconds, but the second loop was stopped after 5 requests. When trying 20 requests every 30 seconds, the requests were stopped 15 into the second loop. 20 requests every 40 seconds was allowed to keep going.

To test the per prim limit again, I linked four of these together, and there were no problems with 20 per 40sec from all four at once. Two scripts in the same prim did not work however, confirming the per prim limit.

Seems like the limit might be around 25 every 25 seconds, but it doesn't like bursts close together

For the record, here's the script I used to test loops (though with the actual URL removed). The PHP script simply echo'd the name sent to it to confirm the request went through.

string      PhpUrl = "http://www.site.com/pingtest.php";
list        PhpPost = [HTTP_METHOD, "POST", HTTP_MIMETYPE, "application/x-www-form-urlencoded"];
integer     Active;
integer     x;

Ping_Test()
{
    llOwnerSay("Start");
    x = 0;
    while(x < 20)
    {
        llHTTPRequest(PhpUrl, PhpPost, "&name=" + (string)(++x));
    }
}

default
{
    touch_start(integer total_number)
    {
        Active = !Active;
        if(Active)
        {
            llSetTimerEvent(40);
            Ping_Test();
        }else{
            llSetTimerEvent(0.0);
        }
    }
    
    timer()
    {
        Ping_Test();
    }
    
    http_response(key request, integer status, list metadata, string body)
    {
        llOwnerSay(body);
    }
}

Good news is bursts still work fine, only now you can do 5 more at a time, and only wait 40 seconds before doing it again

My testing showed no script delay with llHTTPRequest(), the loop was done very quickly, so if you have no idea what the request rate is gonna be for your item, then a llSleep probably would be a good idea. Then again that's true with 1.12.0

Thanks for the testing Kayla, much appreciated. Bursts of 25 should be acceptable I would think, and given it is a per-prim limitation, there are work arounds. lets just hope people don't abuse it so it gets reduced again.

Overall, I'm happy with this improvement, and means I can now make truly functional objects without have to worry about artificial timings or what other objects a person may be using.