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
