[Opensim-dev] Threads, threads, threads and more threads

[diva at metaverseink.com]

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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>