Hi Joel. This is an interesting issue. You would think CPU would be the big issue, but really it isn't.
* We actually do a decent job of time slicing scripts. You add a lot of scripts and in general just the scripts run slower, sim performance isn't that impacted. * WAIT! Before you yell at me for that statement read this one: most of the script sources of lag are *specific* and actually caused by LSL triggered non-LSL events. For example temp-rezzers can kill sim performance. It isn't the script that kills it though, it is the rezzing of the object, and the derezzing. Yes the script causes that, but it isn't script CPU type that is hindering the performance. (BTW we are working on reducing the impact of rezzing! ssshhh) * ALL RIGHT! Yes there are other exceptions, scripts with high script time that effect the sim. But these are generally exceptions. The summary is though, that script CPU time is relatively well handled, though I admit it could be better. * Yes better allocating script CPU time so that one user can't impact the scripts of everyone else is also a great goal - it just isn't as high a priority as script memory right now. moving on.... * Sim's going in to swap is one of the biggest issues with sim peformance we have right now. It is significantly more of a problem than script CPU time. And when it happens all stats tank. * The fact that script memory is unbounded, that you can have a single prim object with thousands of scripts (technically unlimited, but the viewer behaves weird after a while) is a real problem. Someone built a GoogleFS-like system in SL that could in theory hold many gigabytes of data. They thankfully never deployed the full system. * When sims use too much memory they don't just affect themselves they affect their neighbors - the other regions running on the same host. So yeah, it is kind of weird, but memory is the bigger performance issue so we have chosen to address it first. - Kelly PS - nice to chat with you again, feel free to contact me directly if you wanna chat more. Hope things are going well. On Tue, Mar 9, 2010 at 10:49 AM, Joel Foner <joel.fo...@gmail.com> wrote: > Many apologies if this has been discussed at length in a place that I've > missed... > > I'm a bit baffled by the continuing strong focus on memory utilization of > scripts rather than CPU load on the host servers. If (maybe I'm missing an > important issue here) the issue is to avoid a resident or scripted item from > causing performance problems on a region, wouldn't the relative CPU load > imposed by that script be a critical item? > > I understand that if the total active memory size for a server goes above > it's physical available RAM, then paging would increase and potentially > create issues. Is there some objective analysis of servers with the Second > Life simulator code on to show that they go into continuous swap mode in > this case, or is it occasional "blips" of performance degradation on a > slower interval? It seems to me that having continuing excessive CPU load > would generate an on-going low simulator frame rate, which would be more > frustrating than occasional hits from swapping. > > This line of thinking makes me wonder if a better metric for managing the > user's perception of performance would be script CPU load rather than memory > size. > > Thanks in advance, and again if this has already been addressed please feel > free to point me at the thread so that I can read up. > > Best regards, > > Joel > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
