boibandido
New Member
- Joined
- Mar 10, 2017
- Messages
- 3
- Reaction score
- 1
Greetings,
I'm an old opentibia developer (not using my original username, btw) and there's been a long time since I don't work with tibia-related things.
Today an old friend started a conversation with me on Facebook because he wanted help. Actually, he was having trouble with his server saves: he needed them more often but they actually freeze his server when they happen.
When lookin at TFS's source code, I was actually surprised that server save is done the same way it was about 6 or 7 years ago: the game is stopped, houses + house items are saved and then each online player is saved. Also, each player save is actually a complete erase + a lot of inserts (player items, player spells, and there it goes..). It's not actually surprising it takes too much time.
Although they may "hurt", server saves are necessary and sometimes need to happen often (mainly when we change software versions). That said, why hasn't TFS changed its server save system to something like the following:
- Server save starts.
- Save game state in memory cache, which includes (these should not take too much memory space):
1) House data (info+items)
2) Online players data (items, spells, etc.).
- Start a transaction (or even create a new clean database?).
- Starts executing queries to save memory state into database in another thread, one by one, maybe using a dispatcher with a timer.
-If a problem occurs during saving, transaction is rolled back (or new database deleted/ignored) and database is not hurt.
- Since game state was completely saved in memory, no problem if players continue playing, these changes are only going to take effect on next server save.
- If any action inside the game (like a logout) needs the execution of a sql query and a server save is running, then the query is appended and executed after transaction/server save is finished.
Another way of thinking (and maybe even simpler to be coded) is ALWAYS pushing sql queries to a queue. When server save happens, all queries are generated and pushed to the queue (but not executed). Then, server save happens naturally while game runs and other queries are pushed to the stack.
Anyone out there knows if this would actually work?
I'm avid to hear your ideas.
I'm an old opentibia developer (not using my original username, btw) and there's been a long time since I don't work with tibia-related things.
Today an old friend started a conversation with me on Facebook because he wanted help. Actually, he was having trouble with his server saves: he needed them more often but they actually freeze his server when they happen.
When lookin at TFS's source code, I was actually surprised that server save is done the same way it was about 6 or 7 years ago: the game is stopped, houses + house items are saved and then each online player is saved. Also, each player save is actually a complete erase + a lot of inserts (player items, player spells, and there it goes..). It's not actually surprising it takes too much time.
Although they may "hurt", server saves are necessary and sometimes need to happen often (mainly when we change software versions). That said, why hasn't TFS changed its server save system to something like the following:
- Server save starts.
- Save game state in memory cache, which includes (these should not take too much memory space):
1) House data (info+items)
2) Online players data (items, spells, etc.).
- Start a transaction (or even create a new clean database?).
- Starts executing queries to save memory state into database in another thread, one by one, maybe using a dispatcher with a timer.
-If a problem occurs during saving, transaction is rolled back (or new database deleted/ignored) and database is not hurt.
- Since game state was completely saved in memory, no problem if players continue playing, these changes are only going to take effect on next server save.
- If any action inside the game (like a logout) needs the execution of a sql query and a server save is running, then the query is appended and executed after transaction/server save is finished.
Another way of thinking (and maybe even simpler to be coded) is ALWAYS pushing sql queries to a queue. When server save happens, all queries are generated and pushed to the queue (but not executed). Then, server save happens naturally while game runs and other queries are pushed to the stack.
Anyone out there knows if this would actually work?
I'm avid to hear your ideas.