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, <[email protected]> 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 >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ > 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
