Experience throttle and llKeysKeyValue return list size

[LindaB Helendale]

I have two questions about experience tools for which I havn't been able to find any info on lsl wiki, JIRA, or the forum.

There appears to be a quota for experience key-value requests, at least there's error code
XP_ERROR_THROTTLED 1 exceeded throttle The call failed due to too many recent calls.

Would anyone know about the quota and throttling? 

 

The other question is about requesting the key list 
http://wiki.secondlife.com/wiki/LlKeysKeyValue

The returned list may contain less keys than requested "if there are not enough to fulfill the full amount requested or if the list is too large".  Does anyone know what  'too large' means there?

The keys may be 1011 bytes, so if the script has to assume they can all be max size, the script can request around 60 keys, max.  If the keys are shorter (such as compressed keys, 18 bytes) a script can handle a list of 3 000 keys, but since there's no way to filter the keys in the request, some other script in the experience may add longer keys and cause a script assuming short keys to crash. Is the 'too large' related to script available memory (and if so, how?) or is it some fixed size?

 

 

 

 

[Rolig Loon]

You hit the throttle if you use llRequestExperiencePermissions too many times very quickly.  I have not been sure what "too many times" or "too quickly": means, but I know the situation where it commonly happens for me.  If I have tried to use llTeleportAgent and have tried to use llDetachFromAvatar or llStopAnimation in another script at the same time, I will get that error almost every time. You have to do each of those from an experience_permissions event, but if you have two scripts doing it at the same time, they overload the system and it throttles.  The trick, then, is to build a deliberate delay into one of the scripts.  Unfortunately, the throttle applies not only to your scripts but to all scripts within the region, so you need to think about what other scripts might be doing. Usually that's not much of a problem, unless it's not coincidental that several unrelated scripts fire at once.

As far as llKeysKeyValue is concerned, the limit is that you can't list more than about 50 keys at a time. So your guess is in the right ballpark. The trick, then, is to request keys in a batch of 50, process them, and then request the next batch.  It can mean a lot of script time if you are looking for one key out of 2000, but it's doable.  I will typically use llKeyCountKeyValue to see how many keys there are first, and then issue llKeysKeyValue(gStart,50), with gStart == 0 to get the first 50. When the dataserver event has finished with them, set gStart == 50 for the next set, and so on until gStart exceeds the total number of keys.  Along the way, you can filter the growing list of keys you get in return to find the ones you really want to use later.

[LindaB Helendale]

Thanks Rolig, so there may not be throttle in key-value request.

I made some tests (that are pretty inconclusive as it goes with LSL) but it seems that the limiting factor is the event queue. Depending on the length of the available event queue, that's at least 64 but if the server is happy or has idle resources or whatever reason, it can be much longer, I was able to store up to 473 key-value pairs sent in a for loop. After testing a while the event queue reduced to the nominal value 64, but no throttle errors.

For reading the keys, llKeysKeyValue returned 600 out of 1000 keys in one call, with the return value size 8182 bytes, which suggests that the max key list  size could be 8 kB. To test that I made longer keys,  so that 8kB can hold 66 keys with the comma delimiters, and llKeysKeyValue returned 66 keys, taking 8166 bytes.

Conclusion: the size of the key list returned by llKeysKeyValue  is limited to 8 kB.

 

[Rolig Loon]

Fantastic. That's a nice number to know, certainly better than my empirical feeling.  You ought to add a small note in the wiki to share that information.

[LindaB Helendale]

I made more comprehensive tests by choosing different return list lengths (4095, 4096, 4097, 4098) and setting up the key length to make the list  length multiple of (keyLength+1) , which is the key cdl length excluding the status flag "1".

The result is that the whole list can be 4097 characters, 8194 bytes, and the actual list exluding the status flag can be 8 kB or 4096 characters.  For example 128 keys of length 31 characters,.

I added it in the wiki
http://wiki.secondlife.com/wiki/LlKeysKeyValue

This function will attempt to retrieve the number of keys requested but may return less if there are not enough to fulfill the full amount requested or if the list is too large. The length of the returned list is limited to 4097 characters (the success flag "1" and 4096 characters). The order keys are returned is not guaranteed but is stable between subsequent calls as long as no keys are added or removed.

Could someone who knows wiki policies check that it's in the right place and in suitable format (and move/edit if needed). I was not sure if it should be in the definition or 'Caveats'. 

 

 

[Rolig Loon]

That's exactly where I would expect to see a note like that.  It's a quantitative explanation of what "too large" means.  Nice.

LSL scripters are still learning how the Experience functions work, so every new bit of information helps a lot.