ace/Source/ACE.Common/ThreadConfiguration.cs

84 lines
3.1 KiB
C#
Raw Permalink Normal View History

using System;
using System.Text.Json.Serialization;
using System.Threading.Tasks;
namespace ACE.Common
{
/// <summary>
/// We determine the number of available threads using Environment.ProcessCount
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
/// We allocate(int)Math.Max(Environment.ProcessorCount * WorldThreadCountMultiplier, 1) to the World, and the remainder to the database.
/// </summary>
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
public class ThreadConfiguration
{
private double worldThreadCountMultiplier = 0.34;
private double databaseThreadCountMultiplier = 0.66;
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
/*
* Multiplier of 0.34:
* 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
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
* 11 vCPU = 3 thread world, 8 thread database
* 12 vCPU = 4 thread world, 8 thread database
*/
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
public double WorldThreadCountMultiplier
{
get => worldThreadCountMultiplier;
set
{
worldThreadCountMultiplier = value;
var threadCount = (int)Math.Max(Environment.ProcessorCount * value, 1);
LandblockManagerParallelOptions.MaxDegreeOfParallelism = threadCount;
NetworkManagerParallelOptions.MaxDegreeOfParallelism = threadCount;
}
}
public double DatabaseThreadCountMultiplier
{
get => databaseThreadCountMultiplier;
set
{
// This is to support for older configs that do not have this property defined
if (value == 0)
{
var worldThreadCount = (int)Math.Max(Environment.ProcessorCount * WorldThreadCountMultiplier, 1);
var databaseThreadCount = Math.Max(Environment.ProcessorCount - worldThreadCount, 1);
DatabaseParallelOptions.MaxDegreeOfParallelism = databaseThreadCount;
return;
}
databaseThreadCountMultiplier = value;
var threadCount = (int)Math.Max(Environment.ProcessorCount * value, 1);
DatabaseParallelOptions.MaxDegreeOfParallelism = threadCount;
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
}
}
public bool MultiThreadedLandblockGroupPhysicsTicking { get; set; } = false;
public bool MultiThreadedLandblockGroupTicking { get; set; } = false;
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
// World Thread Management
[JsonIgnore]
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
public readonly ParallelOptions LandblockManagerParallelOptions = new ParallelOptions();
[JsonIgnore]
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
public readonly ParallelOptions NetworkManagerParallelOptions = new ParallelOptions();
// Database Thread Management
[JsonIgnore]
Multi-thread landblock ticking (Landblock Groups w/Thread Safety) (#2303) * 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
2019-10-08 20:25:49 -05:00
public readonly ParallelOptions DatabaseParallelOptions = new ParallelOptions();
}
}