[pilif]

I wonder. In a previous post here on HN, somebody said in a comment, that the Sim City infrastructure runs in Amazon's infrastructure.

Isn't one of the big advantages of cloud computing the ability to scale your hardware with demand? Why only scale up by 130% when there's still people having problems? Why not scale until everybody has a good experience?

I don't even think it's going to cost all that much: after the initial onrush, the number of concurrent sessions is likely going to drop rapidly, at which point, they can easily scale down the infrastructure (maybe forcing regions to be consolidated, but as a player I'd rather suddenly have a new neighbor city than a ghost town because my neighbor stopped playing).

If you can scale up by 130% in one week, you can also scale up by 500%. Or however much it takes.

Them not doing this, leads to twoconclusions: 1) they don't care about the current ire among gamers. If the game is good, the rocky start will be forgiven when in two weeks time load normalizes and it will be forgotten within a month. And 2) having overloaded servers due to "unanticipated demand" is in the long run good news to give, increasing the perceived value and quality of the game.

[dietrichepp]

Things don't scale that easily. I'm guessing you're not a programmer.

Question: If it takes 1 server to handle 1,000 clients, how many servers does it take to handle 1,000,000 clients?

Answer: Between 1 and infinity. It might not even be physically possible to serve 1,000,000 clients, depending on the application.

[pilif]

I'm certainly aware of what you are saying. But: if you can scale up the infrastructure by 130% in one week, then you have certainly baked the notion of scalability into your initial design. The fact that scaling to 130% helped makes me think that adding more capacity will help more.

As such, it is potentially also possible to scale up to 200 or 500%, giving even more users a chance to play. I don't expect it to scale linearly with the added hardware, but it will help a bit.

From a technical standpoint, I've learned somethings (from which I'm drawing my conclusions. Bear with me) about their problem:

0) the architecture is hosted on Amazons infrastructure

1) as part of their mitigation, they have turned off the ability to increase simulation speed. This points to a lack of CPU resources on the application servers or a lack of io resources on the backend database to keep up with the increased rate of changes to the data model. However, I've heard from various comments that they might not actually be storing all that state on-the-fly but syncing it at the end of the session at which point the db load would be independent of simulation speed.

I'm inclined to think that CPU starvation on the app servers was likely the reason why they disabled cheetah speed.

Adding more frontend CPU power is quite trivially done by adding more app servers and having each of them deal with fewer concurrent users. In the end, they could use one app server per region (= 10ish cities. Not all of them necessarily being played concurrently) without having to do a lot of additional work in synchronizing region state between machines.

2) https://news.ycombinator.com/item?id=5347611 was talking about database io issues. This is of course a problem you can't just solve by adding more machines as many databases can't easily scale horizontally.

The way how sim city works though lends itself very well to sharding: run regions independently and balance them across multiple machines. Add more machines and rebalance shards (with downtime if you have to, but people weren't able to play anyways)

This is all the information I had to build my opinion on. I did however reflect upon these facts before posting my opinion by which I stand even now.

Being able to scale 130% in a week, having an easily shardable problem and having frontend server CPU starvation tells me personally, that adding more machines could be possible (but maybe not economically feasible).

Of course it's guesswork in the end. But writing these half-technical articles like the submission I linked above do invite guesswork. As long as one has at least some facts to start with, a discussion is still warranted. I have no problem in being proven wrong by additional facts, a different interpretation of the facts or just one article that goes beyond trying to convert PR speech into technical facts (above linked article)

[chaostheory]

"Being able to scale 130% in a week, having an easily shardable problem and having frontend server CPU starvation tells me personally, that adding more machines could be possible (but maybe not economically feasible)."

I strongly feel that this is the real problem, especially since Amazon as extra large instances available now.

[philwelch]

Cloud computing is just cruise control for scaling. You still have to steer.