This link has been bookmarked by 182 people . It was first bookmarked on 14 Sep 2007, by someone privately.
-
20 Dec 15
-
13 Jan 15
-
27 Aug 14
-
08 Jul 13
-
Use explain to how your queries are running. Indexes may not be being as you expect.
- Denormalize a lot. Single handedly saved them. For example, they store all a user IDs friend IDs together, which prevented a lot of costly joins. -
ong running processes should be abstracted to daemons.
-
Most performance comes not from the language, but from application design.
-
-
10 Jun 13
-
04 Dec 12
-
27 Mar 12
-
Saturday, June 27, 2009 at 11:46PM
-
-
04 Feb 12
-
07 Jan 12
-
27 Sep 11
Jochen FrommMaking Twitter 10000 Percent Faster | High Scalability
scaling scalability ruby_on_rails rails performance tuning twitter architecture
-
26 Aug 11
-
29 Apr 11
-
22 Mar 11
-
06 Mar 11
-
02 Mar 11
-
17 Jan 11
-
15 Dec 10
-
11 Dec 10
-
04 Dec 10
Heinz WittenbrinkZur Entwicklung der Twitter-Infrastruktur
-
26 Nov 10
-
24 Nov 10
-
13 Sep 10
-
25 Aug 10
-
01 Mar 10
-
30 Jan 10
-
04 Jan 10
-
24 Nov 09
-
25 Sep 09
-
10 Aug 09
-
14 Jul 09
-
08 Jul 09
-
09 Jun 09
-
02 Jun 09
-
01 Jun 09
-
31 May 09
-
12 May 09
-
07 May 09
-
02 May 09
-
27 Apr 09
-
08 Apr 09
-
04 Apr 09
-
30 Mar 09
-
19 Mar 09
-
06 Mar 09
-
05 Feb 09
-
27 Jan 09
Chris LasherA link-fest for Twitter's explanation of how they solved their scalability issues.
-
12 Oct 08
-
17 Sep 08
-
25 Aug 08
Petter HareimTwitter started as a side project and blew up fast, going from 0 to millions of page views within a few terrifying months. Early design decisions that worked well in the small melted under the crush of new users chirping tweets to all their friends.
webdev web2.0 web twitter toread sysadmin tips server scalability scaling
-
09 Aug 08
-
30 Jul 08
-
22 Jul 08
-
23 Jun 08
-
10 Jun 08
Harjeet SinghScaling Twitter: Making Twitter 10000 Percent Faster
Todd Hoff's picture
Thu, 01/17/2008 - 16:08 — Todd Hoff
* Scaling Twitter: Making Twitter 10000 Percent Faster (2219)
Update 2: a commenter in Twitter Fails Macworld Keynote Test said this entry needs to be updated. LOL. My uneducated guess is it's not a language or architecture problem, but more a problem of not being able to add hardware fast enough into their data center. The predictability of this problem is debatable, but once you have it, it's hard to fix.
Update: Twitter releases Starling - light-weight persistent queue server that speaks the MemCache protocol. It was built to drive Twitter's backend, and is in production across Twitter's cluster.
Twitter started as a side project and blew up fast, going from 0 to millions of page views within a few terrifying months. Early design decisions that worked well in the small melted under the crush of new users chirping tweets to all their friends. Web darling Ruby on Rails was fingered early for the scaling problems, but Blaine Cook, Twitter's lead architect, held Ruby blameless:
For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January. -
29 May 08
-
22 May 08
-
22 Apr 08
-
31 Mar 08
-
03 Mar 08
-
13 Feb 08
-
For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.
-
Abuse
- A lot of down time because people crawl the site and add everyone as friends. 9000 friends in 24 hours. It would take down the site.
- Build tools to detect these problems so you can pinpoint when and where they are happening. -
Abuse
- A lot of down time because people crawl the site and add everyone as friends. 9000 friends in 24 hours. It would take down the site.
- Build tools to detect these problems so you can pinpoint when and where they are happening.
- Be ruthless. Delete them as users. -
Talk to the community. Don't hide and try to solve all problems yourself. Many brilliant people are willing to help if you ask.
-
Cache the hell out of everything. Individual active records are not cached, yet. The queries are fast enough for now.
-
Turn your website into an open service by creating an API. Their API is a huge reason for Twitter's success. It allows user's to create an ever expanding and ecosystem around Twitter that is difficult to compete with. You can never do all the work your user's can do and you probably won't be as creative. So open you application up and make it easy for others to integrate your application with theirs.
-
-
11 Feb 08
-
17 Jan 08
-
04 Nov 07
alex de carvalhoTwitter started as a side project and blew up fast, going from 0 to millions of page views within a few terrifying months. Early design decisions that worked well in the small melted under the crush of new users chirping tweets to all their friends.
howto programming strategy tech tricks twitter webdev stats community advice
-
25 Oct 07
-
10 Oct 07
-
06 Oct 07
-
05 Oct 07
-
04 Oct 07
zigorouどう考えてもマニアック過ぎるけど、そんなkuたんが好き><
api architecture article business caching clustering coding coldfusion optimization ruby scaling performance rails scalability twitter
-
27 Sep 07
-
26 Sep 07
-
21 Sep 07
-
20 Sep 07
-
18 Sep 07
-
17 Sep 07
-
Gary BurgeTwitter started as a side project and blew up fast, going from 0 to millions of page views within a few terrifying months. Early design decisions that worked well in the small melted under the crush of new users chirping tweets to all their friends.
Twitter RubyOnRails scale business systemdesign architecture
-
16 Sep 07
-
15 Sep 07
-
Thomas Vander WalTwitter folks explain how they scaled their system
tech twitter web webdev clustering coding database development howto mysql optimization programming rails ruby rubyonrails server sysadmin
-
Steve GoguenLessons Twitter learned when they needed to scale
-
paulcowlesinteresting article on scaling Twitter, lots of good ideas
-
14 Sep 07
-
- Use caching with memcached a lot.
- For example, if getting a count is slow, you can memoize the count into memcache in a millisecond.
- Getting your friends status is complicated. There are security and other issues. So rather than doing a query, a friend's status is updated in cache instead. It never touches the database. This gives a predictable response time frame (upper bound 20 msecs).
- ActiveRecord objects are huge so that's why they aren't cached. So they want to store critical attributes in a hash and lazy load the other attributes on access.
- Use caching with memcached a lot.
-
- Send message to invalidate friend's cache in the background instead of doing all individually, synchronously.
-
Moved to Starling, a distributed queue written in Ruby.
- Distributed queues were made to survive system crashes by writing them to disk. Other big websites take this simple approach as well. -
Abuse
- A lot of down time because people crawl the site and add everyone as friends. 9000 friends in 24 hours. It would take down the site. -
- Be ruthless. Delete them as users.
-
Build in user limits. People will try to bust your system. Put in reasonable limits and detection mechanisms to protect your system from being killed.
-
For example, they store all a user IDs friend IDs together, which prevented a lot of costly joins.
-
Page Comments
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.