This link has been bookmarked by 5 people . It was first bookmarked on 19 Mar 2009, by Sébastien Bocq.
-
03 Jul 09
-
A very interesting observation during the talk was that Twitter started up with a CMS model and that they gradually moved towards a messaging model. I’ve seen this in a few applications so far, including a casino system, where the messaging model seems to fit best an application intended to power massive community of online users, it seems regardless of what the application actually does business wise. Applications start out completely different, but then more and more functionality gets bolted on top of user messaging capabilities that the whole architecture on the end gets refactored to utilise the messaging channels as the core information transport. With Twitter, I’d expect this to be more obvious from the start as it was intended to help people notify each other.
-
The interesting thing, however, was that all the upgrades were done live, without shutting down the system. The changes were always introduced to one node, then regression issues were sorted out, and then the software would be rolled out to the whole cluster. They went as far as building a whole messaging system based on memcached APIs in order to be able to slot in such changes.
- 3 more annotations...
-
-
a write-through vector cache of primary tweet keys with 99% hit ratio, a write-through row cache for tweets and users with 95% hit rate and a read-through fragment cache with rendered versions of different tweets for different clients with 95% hit rate. All these caches are based on memcached.
-
this change allowed them to increase the web server performance from 3.32 requests per second without caching to 139.03 requests per second. Weaver said that API services work about four times faster than the web, which means that the API performance is roughly 550 requests/s [my calculation, not given during the talk].
-
- Web is only 10-20% of the traffic, the rest is through API services
- Web servers are still 50% of the cluster.
- Regular incoming traffic peaks are around 80 tweets per second. I expected this to be a lot more.
- before the upgrades their web servers shipped only 3.32 requests per second!
- For each tweet, message gets inserted for each user which follows a tweet. In average, a user has 120 followers so this comes to about 9600 messages/s at peak times
- Message servers run on three nodes. They decided to write their own messaging software in order to make the protocol memcached-like, and did not evaluate other available solutions.
- During Obama’s inauguration, they peaked at about 350 tweets per second for around five minutes.
- They had a ton of problems with garbage collection but strangelly haven’t looked into JRockit RT or something similar that has predictable GC. Twitter JVM middleware runs on the SUN JVM
-
-
-
04 Apr 09
-
23 Mar 09
-
-
CMS model
-
-
19 Mar 09
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.