The “Update sessions” latency in the server is too high

[PkllonG]

30 player

[PkllonG]

In the process of using TrinityCore, this error was not found. We may need to port it over.
Among my friends, there are rumors circulating that azerothcore WinServer has more than 900 people and cannot play properly with high latency.
I also found this problem in the actual use process, which is the origin of the above picture.
On the other hand, this may be the reason why azerothcore has so few contributors.

[PkllonG]

On the other hand, there have been fewer contributors since the removal of MariaDB support.
TrinityCore still supports MariaDB.

[Kitzunu]

TrinityCore/TrinityCore#30255 it is just a matter of time before they drop it too. But hey, let's focus on AC.

[Nyeriah]

I don't understand, so using MariaDB causes high update diffs? You are using MariaDB yes? The graphs are using MariaDB?

[PkllonG]

I don't understand, so using MariaDB causes high update diffs? You are using MariaDB yes? The graphs are using MariaDB?

No, it's just a digression, But, What this means is that for those contributors who use MariaDB, they will no longer contribute to azerothcore because azerothcore betrayed them first.

[PkllonG]

This will affect the future development of azerothcore.

[PkllonG]

I've been following azerothcore since 2016 and I hope it gets better and better.

[Kitzunu]

FYI contributions have been an all time high in 2024, and the beginning of 2025 is even better.

Have you thought about using MySQL? It is great

[TheSCREWEDSoftware]

So it's this issue about update sessions /server performance or that we are not using Mariadb and should just because other cores still use it?

Mariadb the way is going will never have support from azerothcore, just use mysql and leave your complex relationship with Mariadb behind if you want to use azerothcore.

[Takenbacon]

@PkllonG Enable & set the following metrics in your worldserver.conf file so we can get a better look:

Metric.Threshold.world_update_sessions_time = 20
Metric.Threshold.worldsession_update_opcode_time = 10

then, recompile the core with the WITH_DETAILED_METRICS flag set (in cmake)

[PkllonG]

I'll use WITH_DETAILED_METRICS for the server tomorrow.

[PkllonG]

[Takenbacon]

Enable preloading of map grids. It's a heavy IO operation that can result in minor spikes until enough of the world is loaded.

[PkllonG]

I try it now

[PkllonG]

I'll test it on the server tomorrow. Thank you for your help with everyone.

[PkllonG]

51 players online
PreloadAllNonInstancedMapGrids = 1

[PkllonG]

[PkllonG]

Obviously we need to optimize it MSG_MOVE_WORLDPORT_ACK

[Takenbacon]

Obviously we need to optimize it MSG_MOVE_WORLDPORT_ACK

Well, yes and no. MSG_MOVE_WORLDPORT_ACK happens during teleports and is almost certainly a result of loading an instance which can be heavy (synchronous queries for instance data, full instance grids loading, creature spawning, etc).

There are improvements that can be made to help out but they require a decent amount of work to do so. Generally, the heaviest operation is still going to be loading up all the initial grids as it basically has to check for, load and parse thousands of gridmap files (as you can see by the name PreloadAllNonInstancedMapGrids does NOT load instance grids, they still are loaded at run time). However, this only happens once per server runtime. Once the base map is loaded into memory it will never have to load the map terrain data again and should be pretty quick. If I'm right you should see most of those spikes disappear over time as the server is running. Personally, I also don't believe a 200ms occasional spike (on the magnitude of once per hour or so) is remotely noticeable by the average player either.

[PkllonG]

Thank you very much for your answers.