The problem is that it's hard to say something defenite on this.
Let's just name some semi-random things:
- If players spam click the attack button, then they open up a lot of sql connections - there is a max limit on them, theoretically one player could block the site for everyone for a little while.
Of course, one player alone can't do everything, but if three players are spam clicking at the same time, and the troop counts are high, it can mean that the entire site is pretty much frozen for a few seconds.
- To ensure there are no weird glitches in, say, same time games, there is a block on the database per game. So only one player can conqueror a territory at the time. If two players try to attack a territory (in the same game) at the same time, then one of them will have to wait x time (not sure what that x is), and then try again (if then someone is attacking, he ...)). This should not change anything for normal games, but same timers (like you) will probably notice this when the server is stressed already.
- Some often executed queries are cached (like the game state - a spectator should get the game state without firing a large query). Of course, this does mean there is less ram available. What happends when a game state is invalidated (changed) all the time?
- The whole idea of how a game works is fundamentally different. Right now all 'moves' are stored in an event log. From there a game can be reconstructed. For example: "kill 3 lose 2, conquering", or place 20 troops at territory y. This way a game state can never be corrupt. Of course, we don't build up every game every query, so a game state is cached (that's how glitches are possible again), and also the turn code is not inside the event log model (because that would be way too much - and it can be reconstructed for the most part, in case of something going really wrong).
In 'the old way' there was one game state that was overwritten everytime sometihng happened (like an attack). This means that there is a lot more chance of getting bugged games (which happened quite frequently) and no way of figuring out what happened (well, there was an incomplete game log....).
This could be quite a bit slower, it could also be quite a bit faster, it's hard to say.
Some of these are things we will look at soon-ish (like the spam attack button thing). Some of them are reallly things we should monitor. Of course, we haven't optimized every query yet, like the old site did. Of course, the old site was also getting close to the limit of what it could have (browse a few news posts and you'll see that we had a server upgrade at some point (multiple points? Not sure)). So by making things a little bit slower means we sudddenly can hit a limit at peek time, which is what's happening now.
I'm curious what would happen if we disable all locks and transactions (apart from weird glitches that is). But really, we can't tell unless we go monitoring specific things, or just try and see if it solves something.
The good news is that all major bugs are fixed (there is one that we aren't sure of, but we haven't seen it in a while, so it probably is fixed). So we have time to look at speed again.
The problem is that it's hard to say something defenite on this.
Let's just name some semi-random things:
- If players spam click the attack button, then they open up a lot of sql connections - there is a max limit on them, theoretically one player could block the site for everyone for a little while.
Of course, one player alone can't do everything, but if three players are spam clicking at the same time, and the troop counts are high, it can mean that the entire site is pretty much frozen for a few seconds.
- To ensure there are no weird glitches in, say, same time games, there is a block on the database per game. So only one player can conqueror a territory at the time. If two players try to attack a territory (in the same game) at the same time, then one of them will have to wait x time (not sure what that x is), and then try again (if then someone is attacking, he ...)). This should not change anything for normal games, but same timers (like you) will probably notice this when the server is stressed already.
- Some often executed queries are cached (like the game state - a spectator should get the game state without firing a large query). Of course, this does mean there is less ram available. What happends when a game state is invalidated (changed) all the time?
- The whole idea of how a game works is fundamentally different. Right now all 'moves' are stored in an event log. From there a game can be reconstructed. For example: "kill 3 lose 2, conquering", or place 20 troops at territory y. This way a game state can never be corrupt. Of course, we don't build up every game every query, so a game state is cached (that's how glitches are possible again), and also the turn code is not inside the event log model (because that would be way too much - and it can be reconstructed for the most part, in case of something going really wrong).
In 'the old way' there was one game state that was overwritten everytime sometihng happened (like an attack). This means that there is a lot more chance of getting bugged games (which happened quite frequently) and no way of figuring out what happened (well, there was an incomplete game log....).
This could be quite a bit slower, it could also be quite a bit faster, it's hard to say.
Some of these are things we will look at soon-ish (like the spam attack button thing). Some of them are reallly things we should monitor. Of course, we haven't optimized every query yet, like the old site did. Of course, the old site was also getting close to the limit of what it could have (browse a few news posts and you'll see that we had a server upgrade at some point (multiple points? Not sure)). So by making things a little bit slower means we sudddenly can hit a limit at peek time, which is what's happening now.
I'm curious what would happen if we disable all locks and transactions (apart from weird glitches that is). But really, we can't tell unless we go monitoring specific things, or just try and see if it solves something.
The good news is that all major bugs are fixed (there is one that we aren't sure of, but we haven't seen it in a while, so it probably is fixed). So we have time to look at speed again.
"Strength doesn't lie in numbers, strength doesn't lie in wealth. Strength lies in nights of peaceful slumbers." ~Maria