game data persistence problem

Started by
10 comments, last by hplus0603 9 years, 7 months ago

One problem I see implied by this design is that the assumption is being made that CPU usage will be the bottleneck when in fact the network and the database will be the bottleneck.

Keep all of the data manipulation logic on the same server and then if you have world physics simulation you may distribute that since physics simulation is CPU expensive.

For example, the main game server could request that a physics sim server do a path check and then accept or reject the request to move from the client based upon what the physics server returns. This means that the main game server can handle other clients while the physics server(s) churn along.

Typical you would distribute logic that takes a long time to run so that the overhead and latency of these servers communicating across ethernet is small relative to the time to complete the action. Game logic routines that perform if this than sql update that are not good candidates. Physics simulation could benefit. Having a distributed database server on multiple physical boxes would most defiantly benefit your read access depending on the DBMS. Your game server probably won't benefit.

Also your gateway server will bottleneck the design even if it passes everything directly through since its ethernet interface will always be slower than the parallel processing of multiple servers.

In reality your WAN bandwidth and database disk access will be your most imminent bottlenecks regardless of how slow and cheap your servers are.

For example, lets say that 100 players stand on top of each other and all cast the same area-of-effect spell.

That means that there are 100 spells hitting 99 targets. Then 100x99 spell damage events. 100x99 hitpoint updates. 100x99 packets x3 (spell start, spell finish, hitpoint update) on the network which is about 100x99x3x80bytes = 2.3 megabytes consumed in 100 milliseconds or 181 megabits per second required to not lag. Of course that assumes tiny 80 byte binary packets and you aren't sending bloated XML or ascii text which would quickly sap your bandwidth.

Now imagine if 3000 players all stood on top of each other and started spamming area-of-effect spells. (That actually happened in dark age of camelot on a regular basis tongue.png )

Even 3000 players in one location simply typing "hello" in chat could DOS your server from bandwidth starvation. It's unlikely that CPU usage would be impacted severely by the game logic involved unless you had physics bounds testing on the server side.

Advertisement

the assumption is being made that CPU usage will be the bottleneck when in fact the network and the database will be the bottleneck


That depends on the specifics of the game. There are certainly lots of game styles where CPU will be a bottleneck before a 10 Gbps network link or an occasionally-checkpointing sharded database.

Network will be a bottleneck if you have a highly sharded simulation model where lots of entities need to have simulation-tick updates from lots of remote network entities.

Database will be a bottleneck only if you design your game rules to need too much hard (persisted) consistency -- like "oh, I fired a bullet; I need to commit this fact to the database!" There are better ways of doing that (including better ways of durable consumables management, such as buffering logs.)
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement