cumulative monitoring can potentially add a bit of server overhead
/serverperformance stop cumulative
/serverperformance start cumulative
ProcessPacket monitoring now also commented out.
* continuing to pull functions out of 1991 while retaining existing functionality
* adding command descriptions
* moving /debugcast and /recordcast to Developer commands
* Improve Multi-threaded landblock group ticking (non-physics)
This splits up the previous Landblock Tick() work into two functions:
TickMultiThreadedWork()
TickSingleThreadedWork()
Mainly, this allows multi-threading of the following work:
Landblock.actionQueue.RunActions();
Landblock creatures Monster_Tick()
Landblock Heartbeat
Landblock Database Save
The first two of which are the biggest CPU consumers from the previous Tick(), and, fortunately enough are pretty safe to multi-thread.
* Make player teleports from portal collisions via physics a thread safe action
* Fix an exception raised in debug mode when creating new characters
* Thread safety for player teleports from death
* ThreadSafeTeleport framework
* More ThreadSafeTeleport cleanup
* AdjustDungeonCells fix
* update AdjustPos comments
* 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
* Code relocation
Moves the landblock tick code from WorldManager to LandblockManager
Individual landblock physics code has been moved to Landblock
* add 5m per landblock monitoring
* remove unused var
* limit landblock stats output to 10 entries each
* Adjust total event requirements
* total column is not needed
* Process inbound GameAction packets in order received
This does not change the performance of ACE. It just shifts the processing to a different order in UpdateWorld()
It changes from an ActionQueue per session for these types of messages to a single action queue per world.
It also changes the order in which messages are processed.
Now, they are processed in the order in which they were received. Before, they were processed session by session, starting with the sessions with lower id's first.
Having two separate queues, one for ClientMessage and one for GameActions helps us measure performance metrics more finely. If we wanted to process both sets of these types of packets in order, we could combine these queues into one.
* Might as well just combine them to simplify things
This also better repsects packet order from the clients.
* /serverperformancemonitor command
Optional parameters are:
start
stop
reset
If no parameters are present, the current performance metrics are spit out.
When disabled, overhead is the cost of some simple function calls and a bool check. When enabled, the additional cost is stopwatch events. In comparisson to the work that ACE does for normal processing, the work done when serverperformance is enabled is nearly 0.
Default is disabled.
Enable it to start up automatically in the config.js. This is recommend for most servers. Enable it at runtime using /serverperformance start
* Fix Reset
