[Opensim-dev] Thoughts on performance with a profiler

[Stefan Andersson]

* There are quite a lot of things that should be indexed, especially those that lock while searching (which I guess more or less all of them do?) - it's become quite apparent that we have thread contention galore in the system.

* I believe that we should start looking at doing more of 'bulk' operations in the database - working with large linksets is one of those things that are really really unoptimized, for example.

* The mark for update was because we wanted to be able to create interest lists and prioritize packet sending by that. Obviously, we don't do that, but that's why we did that model in the first place. I would argue we want to move deeper into working with interest lists and pulling data instead of starting to saturate queues with stale updates.

* +1 on moving stuff out of heartbeat.

* The copies thing is simply as has been said before, the sequence is different. But of course, the payload could be the same. There could probably have been a 'broadcast' function to take a template packet and send to all clients. John Hurliman would probably be the man to do this right for us.

 

Whatever happened to the 3Di packet pool? Are we using that? Did we do the transition fully?

Best regards,
Stefan Andersson
Tribal Media AB



 


From: adam at deepthink.com.au
To: opensim-dev at lists.berlios.de
Date: Mon, 23 Feb 2009 04:08:34 -0500
Subject: [Opensim-dev] Thoughts on performance with a profiler





Test region: 40,000 prims (or there abouts), running trunk. Testing a combination of factors including idle running, idle running with an avatar, etc.
 
Random notes herein:
-          SceneGraph.Get* methods are generally very wasteful. Lots of them use the /slow/ GetEntities method to build a list of entities before searching them. This is particularly noticeable on the GetGroupByPrim(UUID) method. EntityManager should be having indexes for these frequently accessed items.
-          SQLite processing one-at-a-time is very slow. Inserts should be bulked for performance. I suggest running a ‘1500ms’ rule on it.
-          Why, to send a primitive do we need to: - Mark it for updates. – Crawl through the Entities list for updates – Send updates to ClientViews, when we could just Send the update directly to viewers (EventManager.TriggerOnPrimUpdated[?])?
-          Why does Scene.Heartbeat/Update do more than just updating frame-dependent things? Eg, why not keep Update to just: Update Physics, Process Scripts[?], etc. Out of it we move: Backup (timer?), Land update (when something happens+ timer?), Terrain backup (main backup thread?)
-          Why build X copies of the same packet for fifteen separate clients? Why not re-use the update packet and change the agent IDs? Maybe some kind of ‘PacketMaster’ could be developed for each ClientView type which allows us to do ‘bulk’ operations like this.
 
I have a feeling that with a few of these things fixed, performance would increase dramatically.
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090227/5095542c/attachment-0001.html>