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

[Teravus Ovares]

The way OpenSimulator is structured, I really think we need to have
that root agent UDP thread be a full thread.   It handles a LOT more
then the child agents currently.

As far as I know (feel free to correct me if I'm wrong though) , the
child agent, however, does only few things..    Object Updates.
Terrain changes, and connection keepalive.

It would almost make sense to have the child agent be a full thread
for a short time and then be relegated to a worker thread after some
event.   That event could be a certain packet processing threshold is
reached..   or..   the terrain and the objects have been sent to the
client.

As far as I know, the client doesn't disconnect and reconnect the UDP
connection when the client goes from a child agent to a root agent in
the sim (unless they teleport to a distant land)..   so there would
have to be a method for upgrading to a full thread and relegating to a
worker thread.

Best Regards

Teravus


On Thu, Jul 30, 2009 at 11:28 PM, <diva at metaverseink.com> wrote:
> 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
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>