* WIP: Multi-thread landblock ticking
This is the start of "landblock group" ticking.
The idea behind the landblock groups are that each group may contain multiple landblocks that must be ticked on the same thread, but, each group itself can be ticked on independant threads.
The current groups are as follows:
Every outdoor landblock is in a group
Every dungeon landblock is in it's own group (one per dungeon)
This is not ready for public servers yet.
* More changes
* First pass at actual groups
* ObjMaint.KnownPlayers needs to be concurrent
* Removing original PoC code from LandblockManager
* Landblock Tick Cleanup
* VisibleObjects also needs to be concurrent
* DestructionQueue also needs to be concurrent
* KnownObjects needs to be concurrent
* Use a bool to toggle multi-threading
* Add thread safety to SequenceManager
* Move landblock phsyics ticking to LandblockManager
Also
* Cleanup log.Info level messages
Log.info is the default console output and is intended for:
server startup
connection/disconnections
admin initiated command output
server shutdown
Log.Debug is the appropriate level for debug-type messages that are to be logged and audited at a later date, but not output to the console.
* Missed a couple
* Move HandleSalvaging from Warn to Debug
* Add thread safety to Landblock
* More landblock group calc stuff
* couple comments
* Add some thread capping
* Limit database from taking all the threads
This adds limits to the database thread consumption.
It also should allow the world to now consume threads easier.
The way it is done is as follows.
- We determine the number of available threads using Environment.ProcessCount
- We allocate (int)Math.Max(Environment.ProcessorCount * .34, 1) to the World, and the remainder tothe database.
It breaks down as follows
1 vCPU = 1 thread world, 1 thread database
2 vCPU = 1 thread world, 1 thread database
3 vCPU = 1 thread world, 2 thread database
4 vCPU = 1 thread world, 3 thread database
5 vCPU = 1 thread world, 4 thread database
6 vCPU = 2 thread world, 4 thread database
7 vCPU = 2 thread world, 5 thread database
8 vCPU = 2 thread world, 6 thread database
9 vCPU = 3 thread world, 6 thread database
10 vCPU = 3 thread world, 7 thread database
I'd like to get some feedback from this PR on various sized servers.
What you may notice is that loading a player may take slightly longer (very slightly).
What you will probably notice is no discenerable difference in-game.
What I want to make sure happens is that the world doesn't end up feeling more choppy due to the parallel processing of outbound network traffic. Hopefully the more fair thread distriubiton will help prevent thread starvation.
* quit if not enough vCPU
* separate landblock group recal between add/remove
* revert landblockMutex in Landblock.cs
* World Manager AboveNormal thread priority.
* Add some tags
* Couple more
* Create LandBlockGroup entity
* remove space between tags
* Update the log4net examples
* Efficiency improvements
* fix message
* more WIP
* Improve log4net
Add color to console output
Make the default logger use Log4Net.Async
* WIP
* More WIP
* more WIP
* More WIP
* more WIP
* More WIP
* more WIP
* wip
* more WIP
* remove old processor count check
* Create ServerObjectManager
This removes the ServerObjects collection out of ObjectMaint into it's own class.
This paves the way for thread safety that will need to be added to ObjectMaint for the multi-threaded landblock groups.
* Only split if multi-threading is enabled
* remove comment
* ObjMaint refactor
* all obj maint collections are now private
* few more optimizations
* alternate objectmaint thread safety model
* fix
* Remove a couple of comments
* improved ObjectMaint locking
* lock (ThreadConfiguration.WorldLockObject) OnDeath
* progress
* set MultiThreadedLandblockGroupPhysicsTicking to false
* Move a bool
* add lock
* physics ticking thread safety improvement
* use Config.js for thread configuration
* Add config comments
* measure physics ticking performance
* /serverstatus info added
* comments
