Scaling to Hundreds of Millions of Requests: What Worked and What Didn't
Location: Room 307 - 308 Audience level: Novice
All over the web, people are constantly discussing the latest scalable database, the newest testing strategy, or even cloud computing. Claims are made about scalability, reliability, and performance. But by definition, most of this hype is simply conjecture. Its authors rarely have the experience to support their claims.
In the process of scaling our rails app to 150 million monthly pageviews, we’ve tested a lot of these technologies and ideas. We’ve put several popular and supposedly scalable NoSQL database solutions in to heavy production use. We’ve tried testing frameworks and ideas. We’ve deployed both cloud computing instances and physical hardware. Some things worked – others failed spectacularly.
In this talk, I’ll share our experiences, good and bad. These are some of the topics we’ll cover (time permitting):
- Virtualization and Cloud Computing: Virtualized hardware is the default choice for new deployments. That makes sense – it’s easy to get started, and you only pay for what you need. But when (if ever) does it make sense to move to physical hardware? It might be sooner than you think.
- NoSQL: NoSQL is all the rage. There are quite a few solutions, nearly all of them advertised as fast, scalable, reliable. But what is it really like to run and maintain them in production?
- Rails Best-Practices: There are certain practices rails developers take for granted. Automated testing and fat models are a given on almost every rails project. But are these really optimal strategies? Are there ways we can write better-designed, more maintainable code?
- Scaling Rails: Is it as simple as adding application servers? What’s the best system for offloading processing to the background? Does rails scale? We’ll answer the question once and for all.
Since discovering Rails, James has become a prolific contributor to its open source ecosystem. He is the author of several popular plugins and gems, including friendly, resource_controller, and active_presenter. James has contributed to countless other projects, including rails itself.
James is an advocate for well-written, well-tested code and he blogs regularly about the practice of developing software. James is the CTO of Protose Inc.
Comments on this page are now closed.