What helps a sim not to lag ? or be laggier?

[kinda Fallen]

I have a great sim, its a biking sim, where riders seem to enjoy the sights, and love to ride. I am always looking for ways to cut back on lag, so that their rides would be more enjoyable. We have a script counter that allows 150 scripts and 5 MB usage. But it seems anytime someone enters or leaves the sim, of course the wild lag jag hits. Anytime there is over 20-30 people on it, seems the lag is incredible. We do all we can to keep up to date scripting in all things out on the sim, and good textures that are easy to load. Is there anything else we can do? Would appreciate any and all ideas, thanks in advance.....

[Alwin Alcott]

first: delete that script counter, it's useless for several years.....

 

what you can do is be sure only have small textures on your buildings, and avatars with low rendering costs.

20/30 people is quite a lot if they don't care about what they'r wearing.

[Klytyna]

Script counters are kind of problematic, see, there are two kinds of script...

There is the classic lsl, and then there is mono, and here is where script counter memory usage figures fail.

Old lsl scripts often report lower memory usage than mono scripts which ALWAYS seem to report 64kb, BUT, a) the mono script may not be actually using that much, and b) if you have a lot of instances of a mono script, they SHARE memory usage, the server loads 1 copy and assigns data space for each thing using the same script, which saves a lot, so for example, if you had a bike rezzer, that rezzed mono scripted hogs, even though each bike might REPORT a higher memory usage that before, in fact having several mono scripted bikes would use less memry than having them all lsl scripted. Well at least that's the theory we get from LL on their scripting wiki.

A much better performance warning is script count and script time/cpu time. You mentioned big lag spikes when people arrive on sim, this is standard, you see, when you arrive on a sim, EVERY script starts up, does its onRez and onAttach routines and checks etc, you can watch, with the right meter, a person with a script count of 50, and a 200 ms script time, arrive on a sim and for 30-60 seconds, the meter will report them as having a script time of 3-4000 ms. That is your lag spike, but it tends to drop back to normal within a min or two.

Advice for delagging a biker sim... Post a sign stating that use of "rp magical combat huds" will result in a ban, all those damn huds that rez deformers, and spammers and particles and physics effects, and come with rezzed scripted shielding systems, all those "it's not for griefing, no really" huds, autoban any dumb mothers son who you catch wearing one on the sim. Sad fact is a lot of SL's MC members seem to wear such 'combat' items as standard, if you want to RIDE on your track not fight, lay down the club law.

Then check your invisi-squit problem... press crtl-alt-t and do a slow pan in the center of your place, if most of your field of view is foggy red, you have way way too many alpha blend textures, switch to alpha mask, or cut them out, old trees and old grass are bad culprits, banners and flags can be too, wall textures with 'windows' cut in them with alpha, even apparently solid textures can for some unknown reason, have an unused alpha channel in, but SL doesn't know its unused and it jacks the renderweight checking to see if you can actually see through that badly made 'solid brick wall' texture.

Shine... where ever you can replace system shine (the old low med high) stuff with materials based specular shine, it renders better, less gpu lag. Glow... try to avoid large amounts of glow, it's one of the worst renderweight multipliers.

Physical objects can cause lag, those old oildrums or the wooden 'bridge out' barrier on the track you can crash through are fun but, use sparingly. Also avoid persistant temp rezzers, those things that promise to 'cut prim usage' by continually rerezzing temporary items that 'dont count to wards prim usage', just throw those away, they cause major lag if overused.
 

[bigmoe Whitfield]

server side lag?  not really a thing anymore,  CLIENT side lag, yeah that's a massive thing, people blame the servers.  it's the user end hardware that's more to blame. 

people need to realize,  if you are on mainland or a sim with more than one sim, get your freaking draw distance down, especially if your machine is crap and turn shadows off, sure your video card can do it, but you are losing frame rate big times.    and people stop trying to make a 5-10 year old machine perform well, it's not happening and is just choking your experience. 

[Qie Niangao]

7 hours ago, bigmoe Whitfield said:

server side lag?  not really a thing anymore,

Maybe, but this is said to be a "biking sim" and if physics is involved, server-side lag is still a possibility. Also, rezzing of scripts still hits hard -- not nearly as hard as when Mono was new and buggy, yet it's a likely culprit behind time-dilation spikes, especially "anytime someone enters or leaves the sim" wearing scripted attachments.

I'd want to visit this sim and look at sim statistics first before deciding all lag is viewer-side.

EDIT while visiting the sim:

Okay, I'm seeing both server-side and viewer-side considerations here. Server-side, script time is high but Scripts Run is often far from 100% -- and that's not too surprising because there are over 7500 scripts active in the sim. You can use "top scripts" to see better where the heavy-hitter objects are. Just at first glance: there are a bunch of blinking lights done by scripts instead of emissive mask alpha texture animation, there's a script in each flexi flag (see below) maybe to keep them oriented to the wind direction. The big update-senders seem to be the shoutcast board and a swim-animated shark. There's also something very funky with the teleport board, which keeps generating bursts of extremely high script time for objects called "TP (DONT DELETE)" -- it seems like they keep re-rezzing, but I can't imagine why. Also, there seems to be a "follower" that follows me around and burns quite a bit of script time, too. Anyway, these may not be the real heavy hitters because I have no idea where the rest of the 7500+ scripts could be.

Viewer-side, well, there's lots of stuff that could help simplify rendering. Just in the landing area there are a bunch of flexi flags, on flagpoles each with bling on top. None of that has any server-side effect, but it's all extra work for the viewer to render. There's a multiple megaprim sculpty sim surround, which adds to the atmosphere but also the rendering lag. On the surround and local to the region proper there are a bunch of conifers with overlapping blended-alpha textures: more nice atmosphere but also more rendering complexity. Some folks might also quibble with all the particles and animated water textures in the waterfall, but they're pretty essential to the region's atmosphere.

Hope some of those might be useful clues. I can stop in again another time and look around more, if it would be helpful.

Edited April 2, 2017 by Qie Niangao

[Sharie Criss]

On 4/2/2017 at 7:48 AM, bigmoe Whitfield said:

server side lag?  not really a thing anymore

That's absolutely false. Server side lag caused by people TPing in and out is a MAJOR problem for busy sims or anyone relying on scripts / physics.

Years and years ago, shortly after Mono was introduced, there was a HUGE problem with Mono scripts that caused everything on the sim to completely freeze for sometimes 15 seconds. It took almost a year to fix that bug, but the problem of attached scripts is still severe. I run a busy sim (30-50 users pretty much all the time) where people usually have a lot of scripts, and you can easily see in Region tools the impact people have coming and going. I have to restart the sim pretty much daily due to the massive memory leaks in the server code. If I don't, it crashes all by itself in 2-3 days, but in Day 2 and beyond, the lag problem is MUCH worse than Day 1.

The basic underlying problem is that SL is still based on the archaic 1 virtual CPU per (full) region model, meaning that empty sims are given the same resources as busy sims. The problem is, SL is a SOCIAL platform. This means - people actually get together - on the SAME region. Giving the same resources to EMPTY sims, that are ALWAYS empty as busy sims, where people hang out, makes NO sense. Scripts really need to be pulled out of the mainline CPU and given over to a secondary so they don't drag everything down. Sim owners also need Need NEED a way to limit the maximum CPU impact an individual avatar can cause. Let them run 400 scripts if they want, they will just run SLOW because they are limited to X milliseconds of CPU no matter what. LL fixed the Client Side impact of bad avatars with Jelly Dolls, now they need to fix the Server Side impact of bad avatars.

[Alwin Alcott]

9 hours ago, Sharie Criss said:

 empty sims are given the same resources as busy sims.

The problem is, SL is a SOCIAL platform.

Sim owners also need Need NEED a way to limit the maximum CPU impact an individual avatar can cause.

@1 of course... thats where people pay their tier level for ... and its not totally true, sims "travel" in the current server types.. low use ones go to less faster machines

@2 ehm not only ... it's also just a virtual sandbox

@3 they don't need to do that at all

[kinda Fallen]

I want to thank all of you for your fantastic help !

Oie, i found yours to be very helpful, and we will be looking to correct several of the things you mentioned, and thanks so much for taking the time to visit the sim and look this problem over for us. It is an activity sim, so we do have lots of stuff out for them to do while there. We put 5 gaming tables out in the Western Town Saloon, so it could be, but i'm not sure, maybe some of those scripts. They have been updated to the latest versions. LOL who knew that crazy shark was such a mess, he is so gone. Thanks again, and contact me in game if you would like the rights to see the script activity in detail on the sim.

[Pixie Kobichenko]

So, I'm trying to find answers to scripts & lag & how to help my experience improve.  The 3rd response says " Then check your invisi-squit problem... press crtl-alt-t and do a slow pan in the center of your place, if most of your field of view is foggy red, you have way way too many alpha blend textures, switch to alpha mask, or cut them out, old trees and old grass are bad culprits, banners and flags can be too, wall textures with 'windows' cut in them with alpha, even apparently solid textures can for some unknown reason, have an unused alpha channel in, but SL doesn't know its unused and it jacks the renderweight checking to see if you can actually see through that badly made 'solid brick wall' texture."

But EVERYTHING I have rezzed (almost) is red!  

Soooo- is there a type of tree, flower I should look for?  A brand that doesn't make everything red?

I'm also confused by some talk in a group chat about lag- someone asked about lag and they were directed to script info under about lag and then nothing else was said.  I asked what  was considered too big a script, and the response I was given to keep a total of 100 or less.  *blinks* I don't know how that is possible?  Including pictures.  *I just noticed on the script info picture that everything is double listings- i only have 2 what next chairs out.

(I already do things like don't render the sky and keep everything on minimum graphics and only tick basic shaders)  

Edited July 17, 2019 by Pixie Kobichenko

[Profaitchikenz Haiku]

Unless you have written the scripts yourself I would not try to do anything, all you could do with other scripts would be to remove them, which would probably break the items in question. (But see below)

The first and most important question is "do you actually have lag?"

1. Do you rubber-band as you try to move around the region? (connection-issue, all you can do is try to improve your own network)

2. Do things seem to take ages to rezz, or the textures stay blurry for a long while? (texture issue or LI counts, try to get objects with smaller sized textures, or builds with fewer toroids)

3. Do items that have a touch-driven menu take a long time to give the dialog box or seem to ignore your touches? (Scripts are taking too long, this is a known issue LL are working on)

4. Does chat typed into local take a long time to appear in your conversation floater? (Connection issue as above, though Oz Linden recently stated that text itself is also pixels to be rendered therefore any extra workload on the server will give this)

There are other types of lag but I don't have enough personal experience of them to comment.

Some of what people call lag is subjective, if you are in a rush you will find small delays feel like massive ones, if you are mellow and un-hurried the time for textures to load when you turn through 180 degrees is less irksome. Getting an objective measure of how your region is performing day by day is important.

Get to know the figures your statistics bar throws up, things such as simulator time, frame time, physics time, ping sim, packet loss... These will all point to areas where your region is suffering, or else will show you that everything is OK, it's just you that's impatient for things to happen. Once you know what your own region measures, visit other regions and compare both their stats and their subjective feel against your own.

A final thought about scripts. It is only worth spending time looking at those objects where you are allowed to view and possibly modify both the object contents and more importantly the scripts in them. In older content you often find a script that generates the particles given out, or sets the sit position. Since these are both prim properties, of the scripts do nothing else after initialising them, you can remove the scripts from that object, the particles will continue or the sit position remain. Keep them handy in case you want to pop them back in and revise what the prim does.