Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by James Cox on Apr 19, 2007 04:29 PM
Just over a week's gone by and the community is still buzzing with the Rails scalability debate. Developers are asking the defining question: does Twitter prove Rails can't scale?
Twitter is an ad-hoc messaging service originally intended to allow users to update their friends with what they were doing. The status system very quickly changed to ubiquitous conversation - via web, im and sms, with echoes of IRC spread throughout. Coupled with the addition of bots - most notably CNN and BBC feeds being piped through to twitter users - and you're left with a very busy application.
So when Alex Payne - a twitter developer - spoke about scaling their app last week, the first real "can Rails scale?" questions began to surface. This led to an expected fury of commentary from many different corners of the web.
So what really is going on? Alex commented that "there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow." This has since been countered by other commentators, but it's still understood that Ruby isn't the fastest language out there.
Alex goes further, and comments on specific issues with the Rails framework. He highlights the need for more efficient templates (to reduce compute time) as well as multiple database access methods within ActiveRecord. He points out that "once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both."
With the debate truly sparked, Rails creator David Heinemeier Hansson reacted on his weblog, criticizing the Twitter team for having "forsaken [the opportunity to fix it] for an arms-crossed alternative", suggesting instead that the development team are only interested in playing the "blame game".
Reactions have been varied. Many developers and commentators have provided their 'insight' with very little practical outcome. Hansson refers to Magic Multi Connections, a plugin for ActiveRecord as being the tool to solve twitter's problems. Hansson comments: "Williams let code be his reply to the discussion of Twitter's woes on scaling the database. I would of course rather have seen this work come out of Twitter, but I'm happy that they got a free offering handed to them regardless."
In response, Blaine Cook - twitter developer - told us that he thinks "Dr. Nic's approach is a great first step, and adds some welcome helpers to selecting from a number of database connections." but noted that "Twitter isn't currently database bound, and won't be for a while yet". Regarding the problem of scaling Twitter, Blaine points out that "at high levels of traffic, it's really about scaling the application, not the framework. The thing that I love about Rails is that it's flexible enough to let us focus on Twitter and our users."
This prompted to ask him how busy Twitter really is. After some checking, Blaine told us that currently Twitter is serving upwards of 600 r/s - not the 11,000 misquoted by Hansson. Though they are confident that they will reach the 11,000 figure soon enough.
Debate still continues in comment threads and private communities, with some in the community advocating a less aggressive community response. The Twitter team are still relentlessly battling their performance woes. Blaine will be speaking at SDForum this weekend about some of these topics, which is sure to be a packed session. Let's not forget, one the biggest web-applications right now - facebook.com - serves 17,000 req/s. That's almost thirty times more than Twitter.
Dr. Nic, author of the Magic Multi Connections plugin adds "The guys at Twitter have already contributed code to Ruby community (Jabber API), and when they settle on a solution for their situation, I think they will be very happy to share it with us. That will be great. Remember: Rails is 2 years old. .NET + ISS is 7+ years old. Java is 10 years old. LAMP is very old. So, its all in front of us. Exciting times."
The Role of Open Source in Data Integration
Usage Landscape: Enterprise Open Source Data Integration
Ensuring Code Quality in Multi-threaded Applications
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
No comments
Watch Thread Reply