Gojko Adzic » QCon London 2009: Upgrading Twitter without ser...
Popularity Report
 |
|||
|
|||
|
|||
|
|||
|
|||
|
Rank
URL Tag Cloud
Bookmark History
Saved by 6 people (0 private), first by anonymouse user on 2009-03-19
- Joel on 2009-07-03 - Tags twitter , architecture , Performance
- Goodday on 2009-04-04 - Tags twitter , architecture , design
- Rwgd on 2009-03-23 - Tags twitter , scalability , architecture , caching
- Rjhintz on 2009-03-23 - Tags application , management , twitter
- Sebbok on 2009-03-19 - Tags twitter , scala
Public Sticky notes
CMS model
Highlighted by rjhintz
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.
Highlighted by joel
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.
Highlighted by joel
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.
Highlighted by joel
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].
Highlighted by joel
Highlighted by joel
Public Comment