I agree that our use of threads per user has been brute force so far, and any effort to reduce it is a good thing. I don't see any issues in trying what you suggest.
This reminds me of something I observed in the design of parts of the code. In many places we have these worker threads that stay on a loop processing stuff. A recently eliminated one was the old "AssetCache" -- that's gone, and its elimination made things much faster. But there are many more all over, especially those that process things for the client. I wonder if we can get rid of all those threads and move to a fully asynchronous event processing model, leaving the low-level thread management to .NET/mono. I'm not sure we can in all cases, just wanted to raise the issue. Teravus Ovares wrote: > Hey there > > I was just thinking.. does the child agent of an avatar actually > /need/ a full thread? I ask this because we're running up against > the default thread limits of mono in situations where an instance is > servicing your root agent and 8 additional child regions. The > LongPoll fix took the number of threads down by almost half, but, > we've still got a lot more work to do to make it reasonable. Would > anyone object to having child agent worker threads that process more > then one client on the LLUDP side? This would reduce thread usage > by at least 1/3rd over top of the savings that we already have from > the long poll fix. I also note that textures are always served from > the region the avatar is a root agent in.. including textures in > neighbor regions that the avatar sees into. > > A Scenario: > > An instance serves a 9 gridspace set of regions. The avatar logs into > the middle one and creates 1 root agent and 8 child agents on the > instance. > -------- > Before the LongPoll fix: > > Each avatar created 9 threads for LLUDP processing, 9 threads stuck in > eventqueue processing, and several timer/threadpool threads. This > added up 'really' fast. > For example.. at 14 users, there were 252 threads(14 root, 112 > child, and 126 in eventqueue) in use processing the udp stack and the > eventqueue of the users. > > ----------- > After the LongPoll fix: > > Each avatar creates 9 threads for LLUDP processing. There are a total > of 4 threads dedicated to eventqueue processing total. > For example.. at 14 users, there are 130 threads(14 root, 112 child, > 4 in eventqueue) in use processing the udp stack and the eventqueue of > the users. > > ------------ > If we set up worker threads for child agents: > > Each avatar creates 1 thread for LLUDP processing, There are a total > of 4 threads dedicated to eventqueue processing. And, there are (for > this example, we'll say 2 threads per region to process child agents), > 18 threads to process child agents. > For example.. at 14 users, that's 36 threads in use processing the > udp stack and the eventqueue of the users. > ---------- > > Can anyone think of issues with doing this? I would /really/ love > to reduce the thread usage down to 'reasonable' levels here. 36 > threads is WAY less then 252 threads! > > Regards > > Teravus > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
