Twitter Braces For SXSW

Reston: The strains of success -- = traffic -- have been plaguing Twitter for months, and the real test is just ahead: SXSW. Last year, Twitter broke out like herpes as a kissing contest during SXSW, and this year its likely to be hit with like 10X the tongues from 2007.

[from Twitter Details SXSW Traffic Preparation Measures | CenterNetworks]

[quoting a semi-official email from Twitter's Alex Payne]

As part of those steps, I intend to decrease the number of allowed authenticated API requests per hour from 70 to 50 from Thursday, March 6th through Wednesday, March 12th. While we are taking steps to greatly increase our capacity (and have been doing so continuously, particular since our move to our current host), the API is our foremost source of traffic, and as such is the first place we look when trying to create some breathing room for our cluster. I appreciate your understanding, and I hope that 20 fewer requests per hour don't impact your applications too drastically for the duration of the modified rate limit.

We also intend to put some extra abuse-prevention measures in place before the event. We've seen a general increase in abusive traffic over the last several months, and we simply can't afford it during a heavy-traffic event. If you've been scraping Twitter or consuming public API feeds unfairly, be prepared for an unpleasant surprise.

Its acceptable, but not encouraging, to hear that one of the elements of their SXSW plans is to step down access.

What we would all love to hear is that they have ramped up the load-balancing and a reliable integration with a service like Amazon S3, that in principle dynamically scales with demand, so that we can do whatever we like, and the Twitter backbone will work. They threw out the Joyent solution a few months ago, professing love for the company but I guess not for the solution, and went to Verio, I think. Hasn't apparently gotten more stable, though, to my casual eye.

I really don't understand why the nice folks at Jabber, Inc, who parade their performance numbers up and down the street aren't in the mix at Twitter? Shout out to Joe Hildebrand: give these guys some help, please? Or is this going to be a mess until Google or Amazon or eBay or Microsoft buys Twitter?

(Reminds me that a few years ago I was pitching a social service to the Jabber guys -- not Twitter exactly, more like Nerdvana/Friendfeed -- and they were happier chasing their established telephone company business. Still time to get involved guys?)

Comments

[Joe Hildebrand]

As far as I know, the XMPP portions of their infrastructure are not currently the scale problem. Even though they are using an XMPP server we didn't build, we gave them a few pointers on how to optimize their traffic, since we use the service and wanted it to be great.

The biggest problem, as far as I can tell, is the one referenced in the quote from Alex above. People using the HTTP API to poll for changes more than once per minute. If more of the people that wrote Twitter clients would use the XMPP API, there would be several advantages:

• Short latency: find out as soon as people tweet, not when you poll next
• One socket: no need to open a socket once a minute
• No limits: Twitter does not throttle XMPP connections
• No missed tweets: if you get more than 20 tweets between polling, you might miss some with HTTP

We've talked with the Twitter folks enough at this point, I think, that if the XMPP API becomes a bottleneck that they can't address, they'll send us an IM, and we'll spring into action.