A faster login process for DayZ

... there are many ways and which is the best for you depends of your setup ...

Generally i would say, if you don't have a dedicated DB server and additional a very slow I/O (HDD),
you could use some of your left RAM for DB speedup.
Some InnoDB settings allow you to adapt buffer size and other important params.
A very powerful speedup is setting up a RAM-Disk for the transaction log files.
This saves a lot of I/O accesses, but is a bit more unsafe and not recommended if your server crashes often.
If you are really brave, you can (a really stable system assumed) hold the whole DB files in RAM-Disk.
This is very fast but dangerous too and you need procedures to save and restore your files from/to HDD at server start and before shutdown.

Do you have "broken leg" problems too? If yes, did you try the latest publicEH.sqf?
 
fred41 said:
... hmm ..., broken legs with the "conservative" publicEH.sqf? That is a bit surprising for me.
There was a early "experimental" version, where i got some reports of healed broken legs, which appear broken again, with immediate logout/login (db update to late or incomplete).

The "improved" version is the newest and most resource saving at all and SHOULD cause no problems.
But it is new and still evolving (just now updated) and i got no reports at all, so i can't be absolutly sure that it really cause no problems.
If your players report problems with this version, please report it here.

If you really have problems with the "conservative" publicEH, i think the reason for could be that your server is heavy overloaded or very slow db timing.
In this case, i can only recommend, restart more often and/or try to speed up you db . Maybe lowering the max player number helps too.
Click to expand...

I rebuilt pbos with improved version and intant login, I let you know any further problems.
I meant that, with vanilla version no players reported broken legs problem, but only after I put patched version. But you are right, meanwhile I configured a restart every 4 hours (instead of 3 hours). I rolled back to 3 hours. My main server is F34, is full most often, and connects the public hive.
 
For DB speed up, the best would be an evolution in HiveExt DLL:
- the DLL creates a thread
- for any SQL request that the mod does not care the result about (player updates, delete object, insert object) : theses requests are enqueued in a FIFO, without waiting the result (so more CPU for script engine).
- the thread consumes and processes theses requests in background.
- and please, if you update only 1 row, remove these 'prepared statements' : this is slower since they are processed in 2 rounds instead of 1. Or if you keep 'prepared statements', use the background thread to collate similar requests (player updates) in order to update multiples rows at once.
 
facoptere said:
For DB speed up, the best would be an evolution in HiveExt DLL:
- the DLL creates a thread
- for any SQL request that the mod does not care the result about (player updates, delete object, insert object) : theses requests are enqueued in a FIFO, without waiting the result (so more CPU for script engine).
- the thread consumes and processes theses requests in background.
- and please, if you update only 1 row, remove these 'prepared statements' : this is slower since they are processed in 2 rounds instead of 1. Or if you keep 'prepared statements', use the background thread to collate similar requests (player updates) in order to update multiples rows at once.
Click to expand...

I am not involved in the development of hiveext.dll.
But i know the hiveext.dll update mechanism and can confirm your observations.
I think, it is possible that the FIFO queue inside this .dll can be very long (querys have higher priority), if we have slow I/O and very many updates (full server).

Maybe, we should simple lower the update frequence inside the scripted dayz code and for example force DB updates only for player disconnects? That should help servers with bad DB performance a lot.
 
fred41 said:
I am not involved in the development of hiveext.dll.
But i know the hiveext.dll update mechanism and can confirm your observations.
I think, it is possible that the FIFO queue inside this .dll can be very long (querys have higher priority), if we have slow I/O and very many updates (full server).

Maybe, we should simple lower the update frequence inside the scripted dayz code and for example force DB updates only for player disconnects? That should help servers with bad DB performance a lot.
Click to expand...

Please no, I use HiveExt logs to find player teleports. If this is not updated anymore, I won't be able to check that.
Hive requests amount is fine, each player state is updated every 1 or 2 minutes. And don't forget that sometime the server crashes, and with an update only at disconnect, all progress would be lost. I think requests collation is a better approach. For example, store in FIFO all player updates (handler :201:), then every 15 seconds do 1 prepared statement with all these updates.

PS : I know you are not the developer of HiveExt :). What I wrote is not a grief, just my point of view in order to make hive exchanges smoother and to give more CPU to the script engine.
 
facoptere said:
Please no, I use HiveExt logs to find player teleports. If this is not updated anymore, I won't be able to check that.
Hive requests amount is fine, each player state is updated every 1 or 2 minutes. And don't forget that sometime the server crashes, and with an update only at disconnect, all progress would be lost. I think requests collation is a better approach. For example, store in FIFO all player updates (handler :201:), then every 15 seconds do 1 prepared statement with all these updates.

PS : I know you are not the developer of HiveExt :). What I wrote is not a grief, just my point of view in order to make hive exchanges smoother and to give more CPU to the script engine.
Click to expand...

You are right, lowering the update frequence is a bad idea, i forgot all the player tracking tools depending on frequently DB updates too.

My logs show me player_sync events at least each 12 sec per player, and each player_sync event is triggering a db update. You wrote you have state updates every 1 or 2 minutes?
 
I wish everybody a happy new year!

In 2013, i will no longer spend as much of my time in dayz improvements/development.
I hope my work helped some of you to enjoy this game a bit more.
All improvements currently presented here (and some more :) will be part of 1.7.5.

I am curious, what future dayz will have, but i am sure it is a game with a high durability.
 
Hey Guys!

Anyone else having problems with players gettin in?
My server is very fast but often people cant get in, Createvehicle restriction 1?
 
How do I fix this?
We have had server restarts but we still often get the issue.
We have had a hacker problem though.

Any ideas?
 
Have to bring this back: Could it be that they implemented this the wrong way in dayz 1.7.5? Because after 1.7.5 people cant login on server after server is on low fps.
 
You must log in or register to reply here.
Back
Top