(Full Story: Why did Bonobos have such an epic fail on Cyber Monday 2011? – Quora)
Tag Archives: scalability
NoSQL is a Premature Optimization
July 31, 2011
0 Comments
Point 1: NoSQL technologies require more investment than Relational to get going with.
Point 2: There is no particular advantage to NoSQL until you reach scales that require it. In fact it is the opposite, given Point 1.
Point 3: If you are fortunate enough to need the scaling, you will have the time to migrate to NoSQL and it isn’t that expensive or painful to do so when the time comes.
(Full Story: NoSQL is a Premature Optimization)
Netflix Cloud Architecture Slideshare – Velocity Conference 2011
July 5, 2011
0 Comments
Cloud is run by developer organization, traditional IT roles are going away
(Full Story: Netflix Cloud Architecture Slideshare – Velocity Conference 2011)
Akka Project – event-driven, scalable and fault-tolerant architectures on the JVM
June 7, 2011
0 Comments
Using the Actor Model together with Software Transactional Memory we raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.
For fault-tolerance we adopt the “Let it crash” / “Embrace failure” model which have been used with great success in the telecom industry to build applications that self-heal, systems that never stop.
(Full Story: Akka Project – event-driven, scalable and fault-tolerant architectures on the JVM)
Evernote Architecture – 9 Million Users and 150 Million Requests a Day
June 2, 2011
0 Comments
Application redundancy. Each box runs two VMs. A primary VM runs the core stack: Debian + Java 6 + Tomcat + Hibernate + Ehcache + Stripes + GWT + MySQL (for metadata) + hierarchical local file systems (for file data). DRDB is used to replication a primary VM to a secondary VM on another box. Heartbeat is used to fail over to a secondary VM is the primary VM dies. A smart way to use those powerful machines and make a reliable system with fewer resources.
(Full Story: Evernote Architecture – 9 Million Users and 150 Million Requests a Day)
On HTTP Load Testing
May 19, 2011
0 Comments
————————————————————0. Consistency.1. One Machine, One Job.2. Check the Network.3. Remove OS Limitations.4. Don’t Test the Client.5. Overload is not Capacity.6. Thirty Seconds isn’t a Test.7. Do More than Hello World.8. Not Just Averages.9. Publish it All.10. Try Different Tools.
(Full Story: On HTTP Load Testing)
How SmugMug survived the Amazonpocalypse
April 25, 2011
0 Comments
- Spread across as many AZs as you can.
- Beyond mission critical? Spread across many providers.
- Build for failure.
- Understand your components and how they fail.
- Try to componentize your system.
- Test your components.
- Relax. Your stuff is gonna break
(Full Story: How SmugMug survived the Amazonpocalypse)
amazon, aws, ec2, scalability
6 Scalability Lessons from Dropbox – One Million Files Saved Every 15 minutes
March 15, 2011
0 Comments
Poll – Polling 30 Milion Clients All Over the World Doesn’t Scale: Created an HTTP notification structure to avoid polling the server on the client site.
(Full Story: 6 Scalability Lessons from Dropbox – One Million Files Saved Every 15 minutes)
Gowalla CTO on Scaling your Ruby on Rails App for Rapid Growth
March 14, 2011
0 Comments
Most of the “Rails can’t scale” noise is outdated or was misguided in the first place. In general, the question of scalability applies at the level of architecture and systems, and not really at the level of languages and frameworks.
That said, languages and frameworks do definitely have performance and efficiency characteristics that need to be considered. Ruby’s standard interpreter doesn’t have a great reputation for being fast, but as part of a larger, well-architected system, it is very rarely the bottleneck.
(Full Story: Gowalla CTO on Scaling your Ruby on Rails App for Rapid Growth)
Pinboard Creator on Why a Boring Architecture is Good
February 14, 2011
0 Comments
Take advantage of the fact that it’s 2011 and you can load servers up with RAM.Use a RDBMS and take the time to learn it very thoroughly. High-Performance MySQL (the O’Reilly Book) and the Percona blog are indispensible for MySQL; I’m sure similar resources exist for Postgres.Use dedicated (not virtualized) hardware. I/O can be awful on virtualized servers and debugging I/O slowness there is next to impossible.Use caching as a last resort, not as a fundamental design strategy. It’s 2011 – unless you have millions of users, your app should be able to run fast with all caches disabled.Use frameworks for prototyping, but build from the ground up once you know what you’re building.Resist excessive abstractionSet performance targets for yourself. For example, one goal for Pinboard is a median page load time of under a third of a second. This will force you to instrument well and optimize appropriately.
(Full Story: Pinboard Creator on Why a Boring Architecture is Good)
