Twitter survives election after Ruby-to-Java move
Peak traffic of 874,560 Tweets per minute without Fail Whale coming up for air
Ensure Ease of Recovery with Asigra’s Agentless Software
Micro-blogging site Twitter experienced record traffic as the results of the 2012 US Presidential election were announced on Tuesday night, but the service never faltered despite the increased load – something Twitter engineers credit to the company's move from Ruby to Java for its backend software.
According to a blog post by Mazen Rawashdeh, Twitter's VP of infrastructure operations engineering, Twitter users posted an average of 9,965 messages per second between the hours of 8:11pm and 9:11pm Pacific Time.
During a single second at 8:20pm, Twitter users produced 15,107 new posts, Rawashdeh writes, and during the peak traffic period of the evening they generated 874,560 posts in a single minute.
Such numbers are unusual for Twitter, Rawashdeh says, and they represent an evolution in how customers use the service. While in the past Twitter has experienced brief traffic spikes to mark particular events, such as New Year's Eve or the close of a sporting event, this was the first time such heavy traffic lasted for such a sustained period. It was also the highest volume of traffic during an election since Twitter launched.
In the past, Twitter users might have expected to experience problems when the service is under such heavy load. Early in Twitter's existence, service outages were so common that the company's whimsical "fail whale" error screen became a cultural icon for the Web 2.0 crowd.
But Tuesday night's election-driven traffic went off with nary a hitch, which Rawashdeh attributes to Twitter's ongoing migration from backend software written in Ruby and the Ruby on Rails framework to a new software stack built on the Java Virtual Machine (JVM).
Fail Whale sightings were a lot more common when Twitter ran on Ruby. With Java, not so much
Twitter first began stepping away from Ruby in 2008, when the company's Ruby-based message queuing system "hit a wall," in the words of former Twitter developer Alex Payne.
"There's a lot of things that Ruby is great at," Payne said at the time, "but long running processes? Particularly memory intensive ones? Not so much."
Twitter's solution was to migrate some of its Ruby code to a new server stack running on the JVM. Initially, the company's development team avoided stock Java in favor of Scala, an alternative JVM language that combines aspects of object-oriented and functional programming. Today, Twitter's software is built from a mix of Scala and ordinary Java code.
A few Twitter services still run on Ruby, too, but according to Rawashdeh these are used increasingly less often. Notably, he says Twitter has now reconfigured its system so that traffic from mobile devices never touches any Ruby-based software at all.
Where Twitter does use Ruby, it deploys the code on a custom, highly optimized version of the Ruby runtime designed to manage memory more efficiently when executing long-running processes.
None of this will be welcome news to the army of fanatical Ruby developers who believe the language's syntax, its high developer productivity, and its overall philosophy far outweigh any performance disadvantage it might have compared to other languages.
But for Twitter, results are what matter. "The bottom line: No matter when, where or how people use Twitter, we need to remain accessible 24/7, around the world," Rawashdeh writes. "We're hard at work delivering on that vision."
They had better be. Judging by the torrential outpouring of comment on all things related to the recent election, Twitter can only expect its average traffic load to keep climbing as Barack Obama enters his second term as US President. ®
COMMENTS
Re: Not surprised
Dynamic languages suck for large systems. You can't refactor since the tools can't find all potential callers of the code your changing, and you have little confidence anything will work because the compiler can't catch the swathes of errors that a static language compiler can. you find yourself writing enormous quantities of unit and integration tests that are testing the inadequacies of the language rather than your logic - in other words, you're doing the work that would be left to the compiler and static anaylsis tools for a statically typed language. Convention over configuration sucks, since it makes it hard to look at any significant chunk of code and reason about the context it will work in as too much "magic" is going on. A similar problem exists with Aspect Oriented Programming in the Java world using things like ApsectJ, which is why is why this form of AOP should be avoided. The heavy reliance on reflection means performance sucks, and in the case of Grails the framework is a rapidly moving target of new and deprecated features were old bugs aren't fixed but plenty of new ones are introduced.
Do yourself a favour. Do not use Grails or Rails. Use a statically typed language and decent framework - they may not reek of cutting edge cool but they're mature, have good tools and encourage maintainable code.
I've worked in a lot of places hobbled by prototypes.
It can be quick and easy to prototype in something quick and easy but the number of places I've worked in where one or more mission critical apps are still basically stuck in the prototype version and more effort is being spent on maintaining that than would be required to build a full enterprise version.
In fact I know a few extremely large IT companies that still exist because people take that short-termed view at the start and are forever trapped in it.
Re: As a grown up, I say..
Yeah the language or platform doesn't matter - I can write C in any language
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
