1.0.2.3 concerns

[ekroemer]

Hi all,

 

while the 1.0.2.3 patch has alleviated some of the desync/lag problems introduced before, I'm concerned that the problem itself is still present.

 

• We still have fairly frequent (2 times/day) server locks, sometimes only half an hour after the last restart, despite having lowered the max player count to 32.
• The log files are full of 'network message pending' entries, albeit not as many as before.

 

What I personally dislike most: character data takes way too long to be written into the DB at character logout.

When I tell a player to go into the lobby in order to repair his gear/position, all too often the entry I'm modifying in the DB is one outdated several minutes. That holds true when the player completely disconnects.

 

In my opinion character data must be saved immediately on player logout, regardless of any intervals in effect during normal play.

 

Isn't there something you can do to enforce db-write on logout?

 

[vbawol]

Is your server customized and if so what are all of them? What is the server FPS average and what server FPS do you have when you notice this issue.

 

We have some pretty large servers without any reported issues like this.

 

Player data is saved immediately on disconnect if this is not happening for you then I am thinking that you have some sort of custom server code if it is just delayed then that is likely due to the server its self lagging..

[ekroemer]

Difficult to answer as we don't have a root server but are hosted at Nitrado (GER), so there could be a lot of connection or database performance issues that we can't even diagnose, much less rectify.

 

The only FPS info I have is the debug monitor's FPS, that's 45 on average for me; occasionally you see a stuttering at rather high fps.

 

The log file entries about pending network messages don't (at least immediately) show in the client FPS; with more than a few players online there are approximately a dozen entries per second (with 1.0.2.2 we had nearly 1000 per second).

 

On the one hand I'm relieved that Epoch forces an immediate DB update on disconnect ... on the other hand that makes the problem much harder to diagnose.

 

I'll try to get exact information on custom server code from the head admin.

 

On a related note: I dimly remember having read something about some parameters you could set server side to optimize DB (-connection) performance? (Certainly sacrificing other things, but DB seems to be out main problem quite now.)

 

Edit: I just now realize that when our Epoch server shares a root server hardware with other Epoch servers that have not yet updated to 1.0.2.3 we should still suffer from the network traffic those servers create, correct?

[Radiix]

My only question is why the "save to DB" time is measured by playercount?

 

https://github.com/vbawol/DayZ-Epoch/commit/ae12ed5b0d4744d92e011df3de472b7d3672f5cb

 

We should create a looptime where all the stuff is just hardsaved to db every X seconds.

[ekroemer]

I guess they try to keep database load independent from player count.

 

Overall traffic to the DB will scale linearly with the number of players, so stretching the intervall between updates by the same factor is meant to keep DB-traffic per time interval constant, or, simpler spoken, 10 players produce 10 times more traffic than 1 and that the DB might not be able to handle -> save less often with more players.

 

The factor of 2 will be a safety measure as player interactions generate overhead and with more players online there'll always be some at the traders, generating even more additional DB-traffic, so, fudge factor, designed to work for almost all server configurations.