6 ms·

"I saw from the inside a huge multi-mullion dollar Atari-funded game studio go down in flames because the developers didn't know that you can't use disk drives

"I saw from the inside a huge multi-mullion dollar Atari-funded game studio go down in flames because the developers didn't know that you can't use disk drives as a CPU: they built almost all of their MMO item inventory logic into SQL triggers and events." Can someone describe to a newb what's wrong about this?

ucee054 13y ago
If the player character is deciding what loot to pick up from a horde or in a shop trading, there will be lots of inventory logic being fired. Ideally, you want to calculate all the changes, and then write to disk. In practice, you don't know when the changes 'end', so you want to write periodically to disk. If you are using the RDBMS, you are relying on the optimizer to correctly guess what you are doing. When it gets it wrong, it will write continuously to disk. The difference in speed is orders of magnitude, so this one change can easily make your server logic go 10 times slower for no good reason. The problem is worse than this because the RDBMS is not just paging to disk, it's also doing locking/synchronization, thread pooling, tree building and call backs in the background. In every case, it's trying to guess what features are just overhead, and what you really need ... and whenever it gets this wrong, it could be making a pointless system call, which gives you all the overhead of a context switch for nothing. Whereas the gamedev doing this at a low level does not need to guess his own intentions, and uses (and pays cycles for) only those features he needs. You might get away with a database-centric design if your gamedev is really good with databases (dubious) and if you have an appropriate database platform (nigh impossible). But if you have the average gamedev (talented but schlubby and theory-averse) running on the average database (garbage MySQL, ugh!) your performance will DIE.

ucee054 13y ago

If the player character is deciding what loot to pick up from a horde or in a shop trading, there will be lots of inventory logic being fired. Ideally, you want to calculate all the changes, and then write to disk. In practice, you don't know when the changes 'end', so you want to write periodically to disk. If you are using the RDBMS, you are relying on the optimizer to correctly guess what you are doing. When it gets it wrong, it will write continuously to disk. The difference in speed is orders of magnitude, so this one change can easily make your server logic go 10 times slower for no good reason. The problem is worse than this because the RDBMS is not just paging to disk, it's also doing locking/synchronization, thread pooling, tree building and call backs in the background. In every case, it's trying to guess what features are just overhead, and what you really need ... and whenever it gets this wrong, it could be making a pointless system call, which gives you all the overhead of a context switch for nothing. Whereas the gamedev doing this at a low level does not need to guess his own intentions, and uses (and pays cycles for) only those features he needs. You might get away with a database-centric design if your gamedev is really good with databases (dubious) and if you have an appropriate database platform (nigh impossible). But if you have the average gamedev (talented but schlubby and theory-averse) running on the average database (garbage MySQL, ugh!) your performance will DIE.