Scripts and sim performance

Estate Tools don't identify agents. You have to sit on a prim and see what the prim is using to check the scripts. I rcvd a message from Babbage this morning stating that they still have not decided on the UI changes that will show script memory usage. When that becomes available we will also be able to see the resources that an av is consuming script wise.

....But I suspect it's something more directly associated with network connectivity itself: bad cable or connector? flaky ethernet port? routing problem in the datacenter specific to this IP address? Something dumb like that, I'll bet. And only LL can track it down, and only if they watch what's happening on the sim long enough to see it.

Estate Tools don't identify agents. You have to sit on a prim and see what the prim is using to check the scripts. I rcvd a message from Babbage this morning stating that they still have not decided on the UI changes that will show script memory usage. When that becomes available we will also be able to see the resources that an av is consuming script wise.

Happy to say, you're out of date, Jesse.

Top Scripts now shows avatar script usage. Object Name and Owner are both the avatar name.

Unfortunately, but not too surprisingly, time for a sat-upon object still includes the avatar attachment script time. I didn't test enough to tell whether it gets added to the sim total twice.

Memory usage isn't available yet. A couple steps are required before we're to that point, the first of which is on the beta grid now. Folks with memory hogging Mono scripts are advised to test them on the beta grid.

Lear, I agree that script execution by itself should not be able to lag the sim. But again, while I was there earlier, Script Time (whatever that measures) all by itself was larger than the target 22.2ms total frame time. I don't know what that means

, but the one thing that consistently was moving with Script Time was Net Time, which seemed the logical place to focus.

hmmmm mayhap scripts making outside requests? assets, http, rpc, etc? could it be possible some of those are counted in the script time, even if a portion of it runs on the sim time? might partially demystify why similar script time numbers on different sims have a diffeerent effect

also I think the blame on holo rezzors, might just be frequency bias... they rez and remove more often, so they see the problem more often. at least that's a guess based on the still random nature of it.

stopping all scripts may cause loss of incomming data like new uuids, and since the script doesn't know it was stopped it won't know to check for new data. I think the effect is the same as setting all scripts to not running (which still preserves the stack and heap in there current state)

It would count towards script time, but also add server load that does *not* count toward script time. Probably more of the latter than the former.

This is true for temp rezzers, definitely -- esp if the prim count is high. For holodeck-style rezzers (which rez semi-permanent objects), the scene is generally used infrequently, so the only expense is the (mostly idle) script in each rezzed object that listens for a command to die. If a rezzer rezzes LOTS of objects, this can add up.

If the sim has been restarted since this problem started -- and, with the rolling restarts, odds are its been restarted more than once --- would that rule this [network glitch] theory out?

I had thought that the "conductor" does load-balancing when sims are restarted. If so, wouldn't it be unlikely that a given sim would end up on the same core (or even computer) when it is restarted?

As the simulation is software & the hardware changes with every re-boot, this takes the possibility of a faulty island out of the equation. The main factor that's currently effecting this region is the content, for example.. if we were to delete half the content within the region, you'll see a significant increase in performance.

As you have been informed on the Forum, 1.26 does have some major updates to resource handling, specifically with Mono Scripts. The updates are still ongoing and not yet completed. I have however, updated your island right away, to see if there is an improvement.

Please allow the region to run for a couple of days and see if the performance improves. If you are still having issues, you may need to go through your Top Scripts List and try to identify what items are mostly causing the high value.