Avatar script count limit on homestead

[SeeAirAhh Josephina]

I have limited the script count for avatars visiting my homestead to 50, I received that recommendation from the people I rent from.  I wanted to know if others agree with that or should it be 75?  

[Wulfie Reanimator]

As long as it's under a hundred...

Avatars can have up to 38 attachments. If they have more than two scripts per attachment on average, somebody's doing it wrong. Not everybody even knows how to check their script count, and/but there's not always a way to remove scripts from attachments, so it's a little subjective.

The biggest impact of script count happens while the avatar is in the process of teleporting in. After they're already in the sim, kicking them out won't help very much. The majority of overall script lag comes from permanently rezzed things in the sim, so that's where your optimization should focus.

[Maitimo]

Personally I feel that 50 is enough; even with a mesh body and head, I have no problem keeping mine down at around 30 or lower. People need to get out of the habit of travelling round the grid with their head and body huds still attached.

But I am sure that whatever you set it to; 50 or 75 or even higher, someone will complain.

(Just checked and I'm currently carrying 24).

Edited January 23, 2020 by Matty Luminos

[SeeAirAhh Josephina]

I only have 18 but I'm a toddleedoo, I only had 1 person say something tonight but they were both men with those huge muscular avatars.  I gave them a script checking hud.

[Rolig Loon]

Personally, I can't imagine anyone needing to carry around as many as 50 scripts.  I have 18 on me at the moment, and 4 of them are in a pair of HUDs that I am testing with, so I only wear them while I'm working on my own region. 

[SeeAirAhh Josephina]

I appreciate all your responses, unfortunately the meter I'm using doesn't tell me when it kicks someone, I may look for something else.  

[SeeAirAhh Josephina]

So I've been sitting here tonight watching the board as people enter and several people are well over 100, the 50 script count seems to be easy for the kids

[Wulfie Reanimator]

2 hours ago, SeeAirAhh Josephina said:

I appreciate all your responses, unfortunately the meter I'm using doesn't tell me when it kicks someone, I may look for something else.  

Assuming you own the whole region, here is a very simple script that:

1. Checks the script count of every avatar in the region, every 30 seconds. If they have too many scripts, it will:
   1. Send them a message, explaining that they have too many scripts and how many.
   2. Send you a message (if you are in the same region), telling you how many scripts they had.
   3. Eject them.

You can put this script anywhere in the region, as long as it's rezzed.

integer frequency = 30;
integer too_many = 100;

default
{
    state_entry()
    {
        llSetTimerEvent(frequency);
    }

    timer()
    {
        list avatars = llGetAgentList(AGENT_LIST_REGION, []);
        integer total = llGetListLength(avatars);

        integer avi = 0;
        while (avi < total)
        {
            key avatar = llList2Key(avatars, avi);
            list data = llGetObjectDetails(avatar, [OBJECT_TOTAL_SCRIPT_COUNT]);
            integer scripts = llList2Integer(data, 0);

            if (scripts > too_many)
            {
                llRegionSayTo(avatar, 0,
                    "Hi! Your script count is too high (" + (string)scripts + "),"
                    + " please be considerate of other people and reduce the amount.");

                string profile = "secondlife:///app/agent/" + (string)avatar + "/profile";

                llOwnerSay(profile + " had " + (string)scripts + " scripts.");

                llEjectFromLand(avatar);
            }
            ++avi;
        }
    }
}

 

Edited January 24, 2020 by Wulfie Reanimator

[Lindal Kidd]

I see little reason to limit the scripts on your visitors.

[Alwin Alcott]

6 hours ago, SeeAirAhh Josephina said:

I have limited the script count for avatars visiting my homestead to 50, I received that recommendation from the people I rent from.  I wanted to know if others agree with that or should it be 75?  

as a normal region can have up to 100 avatars, and a homestead with a quarter of the resources ( in general) but also just a quarter of the visitor count, i see not a lot reason to really limit it down... better aim at a lower texture resolution on all builds and items, if it's still a lag pit, start with going to 20 visitors instead of 25 .
If your homestead is lagging by the way you use it you perhaps belong at a full region.

[Odaks]

Isn't script usage, rather than script count, a better indicator of potential problems?

Is it not the case that a single, highly active, script can be more demanding on the server than, say, 100 idle scripts?

Should we be monitoring script time, not the total number of scripts?

[Mollymews]

2 hours ago, Odaks said:

Should we be monitoring script time, not the total number of scripts?

yes agree

adding to the conversation

OBJECT_SCRIPT_TIME as you say.  And we can use OBJECT_RUNNING_SCRIPT_COUNT to know, without any potential ambiguity, when people are or not, heeding our request to reduce their active script load on the server

the algorithm is typically

1)  Periodically,  GetRegionTimeDilation.  When this drops below a time designated by the region/parcel owner then goto 2) else goto 1)

http://wiki.secondlife.com/wiki/LlSetTimerEvent

http://wiki.secondlife.com/wiki/LlGetRegionTimeDilation

2) Get each agents OBJECT_SCRIPT_TIME and OBJECT_RUNNING_SCRIPT_COUNT

if ( agent is marked (from 2a) ) then

-- check that their current OBJECT_RUNNING_SCRIPT_COUNT is less than their 2a) previous

-- if (so) then { do nothing to them as they have complied }.  If (not so) then { they haven't complied, so kick them from the region }

http://wiki.secondlife.com/wiki/LlGetAgentList

http://wiki.secondlife.com/wiki/LlGetObjectDetails

http://wiki.secondlife.com/wiki/LlTeleportAgentHome

2a) ask the person (or persons) with the highest OBJECT_SCRIPT_TIME to please remove some scripts. Save/mark that we have asked them nicely

goto 1)

[Qie Niangao]

2 hours ago, Odaks said:

Should we be monitoring script time, not the total number of scripts?

They're two different contributors to the same kind of lag (mostly scripts lagging other scripts), and they're far from independent. The biggest problem with measuring script time is that it's a fantastically unstable metric. Some of this may be the measurement process itself and some of it is the true effect of starting a script, but either way: if you measure a newcomer's script time 0.2 seconds after they arrive it will be many times larger than a half second later, which in turn will be massively larger than two seconds later, and it doesn't really settle for minutes -- even if they're wearing just a couple scripts that don't even have active event handlers. At least some of that is real: it's super costly to load up a script into the simulator (even if it never does anything once loaded); some of it may be an artifact of how the statistic tries to generate a number from one or two instantaneous samples of "who's got the CPU?"

The other factor here is that script count matters even after the scripts are loaded into the sim, even if they have no relevant event handlers. We've known this for over a decade: the more scripts the scheduler knows about, the slower it is at running those that might have an event pending. The Lindens know about this and there's some interest in improving general script execution efficiency, but I suspect nothing much will happen here until the cloud migration is behind us.

(Just in passing: script count is about as good a measure of memory usage as the memory metric itself. It's sorta not worth mentioning these days because script memory doesn't seem to be a problem for sims these days.)

[Mollymews]

5 minutes ago, Qie Niangao said:

The biggest problem with measuring script time is that it's a fantastically unstable metric. Some of this may be the measurement process itself and some of it is the true effect of starting a script, but either way: if you measure a newcomer's script time 0.2 seconds after they arrive it will be many times larger than a half second later, which in turn will be massively larger than two seconds later, and it doesn't really settle for minutes -- even if they're wearing just a couple scripts that don't even have active event handlers

agree with this

we have to be polite I think as best we can by giving the person some reasonable time for things to settle down, then ask them to reduce some scripts when warranted, and only boot them at some later time if they haven't complied with our request

[Qie Niangao]

Maybe the responsible approach would be two-stage: count up their scripts and if it's > 100 (say), boot 'em right away and tell them to remove stuff. Then, for the ones with reasonable script count, give 'em a few minutes for the script time metric to settle and if they're still burning an unreasonable lot of CPU, warn, measure again in a minute or so, then boot if they haven't gotten down to good numbers.

(It occurs to me that I've only ever paid attention to script time in fairly well-performing sims. I'm wondering how much time a script could get in a region with way too many other busy scripts. That is, is it harder to exceed our "too high script time" threshold the worse the problem is for the sim?)

The other thing I'd mention here is that any of this can only address the "scripts lagging scripts" kind of lag. It will do nothing for a sim in time dilation, nor any sim with large non-script competitors for frame time (physics, network, simulation, etc.). These tidy measures of script impact don't measure the effect of scripts that trigger those other effects despite burning little script time (e.g., a griefing replicator may have inconsequential script time while dragging the sim deep into physics dilation).

I guess that's all to say these script lag management devices have only a very specialized utility, so unless one is really sure there's a relevant problem to solve, it just won't be worth doing at all. (Put another way: Reducing a sim's script load will not make lag any better except in the relatively rare cases where script-on-script lag is the only problem. Otherwise, addressing the real problem is likely to make evident that script-on-script lag was never a problem to begin with.)

Edited January 24, 2020 by Qie Niangao

[Cinos Field]

Script memory is what I go by, personally. Even with all bells and whistles a technically adept user shouldn't have more than 1mb, but you have to have some leeway for casual users. 5mb or so is, I think, a fair limit and what most people fall around.

Script time is also an option, but it fluctuates a fair bit. 0.1-0.2ms seems like a fair range, though.

One big problem is that a lot of creators, particularly those making women's clothing, will not let you delete recoloring scripts and the like, so people tend to have far more of them than needed, and it's not the user's fault. But that's how it goes.

[Qie Niangao]

Script memory is really 64K * script count, to a first approximation, and the difference between those numbers just isn't meaningful. At all. That's because llSetMemoryLimit() has only downside risk, so practically nobody uses it. It does not affect the amount of memory used by the script, and there's no way outside the script to even measure how much memory is actually used by the script (as opposed to the upper limit on how much it is allowed to use).

There are still a few old LSL-compiled scripts in use, and they'll come in at 16K (which is what they actually use, even if they need much less). There's so much weird about LSL-compiled scripts that it's apples-and-oranges anyway (although they do load a tiny bit more efficiently when handing off to a new sim).

[Wulfie Reanimator]

For some additional context, since I did talk to OP:

Supposedly, 4 avatars on the sim as fine, but 9 was causing noticeable lag.

The homestead sim is running at 50% scripts while the total script count is ~1200.

I can only think of other homestead(s) being overloaded on the same server and/or things like physics problems, but I didn't visit the sim myself. It's important to note that scripts are the very last things to run, after all other tasks. If the sim spends a lot of time working on non-script related processes, scripts won't get much time to run no matter how "low-lag" they are.

1 hour ago, Qie Niangao said:

There are still a few old LSL-compiled scripts in use, and they'll come in at 16K (which is what they actually use, even if they need much less). There's so much weird about LSL-compiled scripts that it's apples-and-oranges anyway (although they do load a tiny bit more efficiently when handing off to a new sim).

You mean LSO. Also, LSO scripts initialize much faster during teleports and while the object is being rezzed. The difference is huge, especially noticeable during teleports (in the arriving sim) and fast-rezzing things like bullets. Though, LSO runs much slower than Mono, and uses less script time overall. /ramble

Edited January 24, 2020 by Wulfie Reanimator

[RoxyCyn]

On 1/24/2020 at 2:29 AM, Odaks said:

Isn't script usage, rather than script count, a better indicator of potential problems?

Is it not the case that a single, highly active, script can be more demanding on the server than, say, 100 idle scripts?

Should we be monitoring script time, not the total number of scripts?

Yes, script count itself is not an accurate measurement or way of predicting usage.  The amount of memory used in mb is the more important number.  It's been a long held myth or urban legend that the greater the number of scripts, the greater the lag.  There is some truth to this in a general sense in that usually as the number of personal scripts increases the more affect it has.  That's a very broad statement and only partially true but not in all cases.  You could have more running scripts on your avatar and use less memory than someone else using fewer scripts.  

Running a full region for riding motorcycles you see a lot of people riding with a lot of unnecessary (for the purpose of riding) scripts running.  Often I see people running scripts consuming memory of over 5.00mb.  A simple, but well dressed avatar in full mesh body and clothing can easily keep their script memory down below 1.25mb and often less than 900mb if they make the effort.  I have 'low mb' outfits in my wardrobe for the explicit purpose of riding/flying/boating/whatever.  It's very easy to do, but sadly most people don't even bother to lower the usage.  It really does make a difference.

Edited January 27, 2020 by RoxyCyn

[Wulfie Reanimator]

1 hour ago, RoxyCyn said:

Running a full region for riding motorcycles you see a lot of people riding with a lot of unnecessary (for the purpose of riding) scripts running.  Often I see people running scripts consuming memory of over 5.00mb. 

You can't get accurate script memory usage as an observer, it's about as useless of a metric as script count. (Unless you're an estate manager, but I think LL changed even that method.) You can only find out the maximum memory limit; 64KB for Mono (lower if it uses llSetMemoryLimit) or 16KB for LSO.

Mono scripts use memory dynamically. That means that a small script might use 5KB out of 64KB.

LSO scripts are fixed-size. They always use 16KB no matter how big of small the script is.

Edited January 27, 2020 by Wulfie Reanimator

[RoxyCyn]

Sorry if I was not clear.  I am the estate manager.  I'm not saying memory is the best way of measuring, but from an estate manager perspective it's a quick way to determine the region's overall health and what's causing any issues as compared to a strict number of scripts count.  Most importantly though the resulting lag experienced by the rider is mostly a result of their scripts.  This is a fairly short, simple way for riders to see it when displayed on a board, if they care.  My point was simply that a lot of riders with plenty of experience ride with excessive scripts regardless.  Some care and others don't.  From my perspective, when I run low scripts, I ride better and everything performs smoothly within reason considering the location and the day of the week (ie: peak times).   Everyone has different tolerance levels for how much lag they want to deal with. 

[Qie Niangao]

Now that I think about it, it's been a long time since we've heard from a Linden that script memory was practically never a consideration in how well sims handle scripts, this in contrast to how things were when Mono was new, there were bugs in how scripts loaded, and sim memory was much smaller. I've been assuming that this problem, once solved, has remained solved, but we may actually have more scripts demanding more memory now than we did then, so it would be good to reconfirm that script memory still isn't an issue.

Of course, being unable to see internal sim state, we could find that a script memory metric nonetheless correlates highly with a sim's script performance, even if memory itself is never an issue, simply because memory correlates so very highly with script count; as I said above, to a pretty good first approximation, they're measuring the very same thing.*

One difference, though, is that one can choose to look at running (rather than total) script count. All scripts, running or not, must be loaded into sim memory, so it makes sense that there's only one memory metric, total for all scripts regardless of running state. The running script count is an early, crude but stable proxy for how much impact those scripts may have on the sim, including a very coarse hint of their script time ("coarse" as in "it's not impossible they might do something sometime").

___________________
*The script memory metric is actually a better proxy for script count than it is a measure of script memory use. That's because, as Wolfie and I have mentioned, Mono scripts do not report actual memory use, only their upper limit, which is almost always left at 64K. This can be pretty misleading, especially comparing LSO ("LSL"-compiled) and Mono scripts. Many simple Mono scripts use under 8KB -- half of what every LSO script uses -- but report their 64K limit -- four times that of an LSO script.

Looking at it a different way, comparing avatars wearing only Mono scripts, both actually using 64KB, one may report 64KB and the other 512KB (or even more). Now, there is a reason the one reporting 512KB might hurt sim performance more: it uses the same amount of memory but it's split up among more scripts.

[Qie Niangao]

On 1/28/2020 at 11:09 AM, Qie Niangao said:

Now that I think about it, it's been a long time since we've heard from a Linden that script memory was practically never a consideration in how well sims handle scripts, this in contrast to how things were when Mono was new, there were bugs in how scripts loaded, and sim memory was much smaller. I've been assuming that this problem, once solved, has remained solved, but we may actually have more scripts demanding more memory now than we did then, so it would be good to reconfirm that script memory still isn't an issue.

I tried to ask about this at the Server User Group, but I think the Lindens (quite reasonably) supposed I would argue for script memory limits larger than 64KB, when all I was really hoping to learn was whether script memory under the current limits ever cause problems in sim performance these days. I think we have no more information about that than before I asked, unfortunately.

On 1/24/2020 at 5:47 AM, Qie Niangao said:

(It occurs to me that I've only ever paid attention to script time in fairly well-performing sims. I'm wondering how much time a script could get in a region with way too many other busy scripts. That is, is it harder to exceed our "too high script time" threshold the worse the problem is for the sim?)

This question kept nagging at me, so I wrote a little script that sampled my own script time, and took it with me to several regions with a range of loads, and a corresponding range of Scripts Run percentages or Spare Time. For a while I was puzzled. It seemed the opposite from my prediction was happening: the worse the sim's script performance, the more time my scripts seemed to be taking. By a lot.

Then I realized I'd never really been patient enough to let my script time numbers settle all the way, so I decided to do that. Here are a couple graphs (note the Y scale is logarithmic for easier viewing) :

Confirming the earlier finding, in the heavily loaded FaMESHed region, my script times start out much higher, peaking about 5 seconds after arrival at 0.135 seconds (a whole frame is only 0.022 seconds), compared to the Myron region which peaked right after arrival at 0.031 seconds script time. But then things get interesting. In Myron, the metric stabilizes at 0.000085 about ten minutes in; FaMESHed takes almost twice as long to stabilize but reaches a time of 0.000041, showing my avatar getting less than half as much script time in the much busier sim than in the nearly idle one.

I haven't tried very hard to make sense of what these numbers tell us about how the script time measurement is made nor the implications for interpreting it, other than to note just how very unstable the metric is, and how very long it takes to stabilize. I subjectively knew it was taking a while but I really had no idea how bad it is, nor how much less stable it is when measured on regions with real performance issues.

[Wulfie Reanimator]

17 minutes ago, Qie Niangao said:

I haven't tried very hard to make sense of what these numbers tell us about how the script time measurement is made nor the implications for interpreting it, other than to note just how very unstable the metric is, and how very long it takes to stabilize. I subjectively knew it was taking a while but I really had no idea how bad it is, nor how much less stable it is when measured on regions with real performance issues.

Just to clarify in case this detail isn't clear (and to anyone reading to explain the drop): Script time is an average over the past (up to) 30 minutes, or since the script's last rez or restart.