4 ms·
How FarmVille Scales to Harvest 75 Million Players a Month
- z8000 17y agoI wish there was more data offered! Request-response, XHR, long-polling, "COMET" (blarg, I hate that moniker) when talking to the backend?
- axod 17y agoDon't forget WebSocket ;)
- z8000 17y agoTrue, but I don't think development versions of browsers have 75MM users at this time. Maybe in 2020 when HTML5 is ratified. :)
- axod 17y agoFWIW, close to 10% of Mibbit are already on WebSocket. It's supported in the non-dev latest Chrome, which the majority of Chrome users are using, since the browser has a proper update facility. Ignore things at your peril, although you're probably right. People playing FarmVille are unlikely to be early adopters.
- catch23 17y agoI'm betting majority of farmville players are on work computers... instead of solitaire or yahoo games, there's farmville!
- pavlov 17y agoIsn't FarmVille a Flash game? If so, it presumably uses Flash XML sockets instead of Comet-style browser hacks.
- richcollins 17y agoHe said that they're using LAMP. I'd like to hear more about how they deal with schema updates and how they model their data in general.
- teej 17y agoAs far as I know they... don't. MySQL is used more as a persistent store for bits, not as a relational database.
- ehsanul 17y agoThey use cache components to scale their writes, since they have so many writes. I assume this means that instead of hitting disk for every write, data in the cache is updated instead, and asynchronously saved to disk. Really, this pattern should be generalized, in some sort of memcached extension/fork or something.
- aristus 17y agoMySQL has this in the form of the startup option innodb_txn_commit. It performs all writes to memory and flushes them to disk in 1-second batches. It's a good way to scale up to 000's of writes per second per machine.
- ehsanul 17y agoNice, but when you're scaling to such a large size, you probably want to go NoSQL, unless you use MySQL as a key-value store (which I've heard of some people do). Another thing: Many applications, can get away with updating to disk much less often, say every 30 seconds or even longer if appropriate. When a machine fails then, you lose 30 seconds worth of updates stored in that machine's RAM, which may be fine. For some applications, you could probably stand losing even a few minutes of updates on a failure, while gaining huge decreases in loads on disk.
- z8000 17y agoYes, you could buffer writes. Tokyo Cabinet does this for instance as does Redis. There was an article on the mysql performance blog about Tokyo and how fsync()ing at 1Hz didn't adversely affect performance; there are other issues with TC but that's not my point. I suppose a system where data could be lost if buffered in RAM for up to 30s could replicate to other hosts in the cluster with the (perhaps naïve) intuition that the probability of > 1 hosts going down within the same 30s interval is low -- "someone's got the data somewhere!". Of course, if they are on the same source of power... :) One could use a consistent hashing scheme as employed in Riak and others for read operations in such a setup and thus be a bit more fault-tolerant (hand waving a bit). This is without any hard-earned experience with this other than reading... Thoughts?