Commit Graph

5 Commits

Author SHA1 Message Date
Justin Clark-Casey (justincc)
86367d7219 refactor: Move methods to start a monitored thread, start work in its own thread and run work in the jobengine from Watchdog to a WorkManager class.
This is to achieve a clean separation of concerns - the watchdog is an inappropriate place for work management.
Also adds a WorkManager.RunInThreadPool() class which feeds through to Util.FireAndForget.
Also switches around the name and obj arguments to the new RunInThread() and RunJob() methods so that the callback obj comes after the callback as seen in the SDK and elsewhere
2014-11-25 23:56:32 +00:00
Justin Clark-Casey (justincc)
cfc4055991 Make outboudn and packet inbox handling threads highest priority.
Will only have any affect under Windows or mono with a patch such as https://gist.github.com/justincc/31e52218d098529b4696 (not recommended) applied.
For assessment purposes.
2014-11-25 23:18:38 +00:00
Justin Clark-Casey (justincc)
e4d16e6795 Make LLUDP output queue refill thread active by default, since load tests have shown that this has better scalability.
For testing, previous behaviour can be restored with the console command "debug lludp oqre stop" at runtime.
2014-09-04 18:24:59 +01:00
Justin Clark-Casey (justincc)
88b2fc61ff Add clientstack.<scene>.OQRERequestsWaiting stat
Only present if OQRE is enabled
2014-08-19 00:42:19 +01:00
Justin Clark-Casey (justincc)
84cea46c10 Add experimental OutgoingQueueRefillEngine to handle queue refill processing on a controlled number of threads rather than the threadpool.
Disabled by default.  Currently can only be enabled with console "debug lludp oqre start" command, though this can be started and stopped whilst simulator is running.
When a connection requires packet queue refill processing (used to populate queues with entity updates, entity prop updates and image queue updates), this is done via Threadpool requests.
However, with a very high number of connections (e.g. 100 root + 300 child) a very large number of simultaneous requests may be causing performance issues.
This commit adds an experimental engine for processing these requests from a queue with a persistent thread instead.
Unlike inbound processing, there are no network requests in this processing that might hold the thread up for a long time.
Early implementation - currently only one thread which may (or may not) get overloaded with requests.  Added for testing purposes.
2014-08-19 00:17:12 +01:00