Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
The story of the quest to make bundle install faster; in which Rubyists around the world inadvertently DDoS rubygems.org, witness its ignominious death, and vow to rebuild it from the ashes stronger than it was before. Then, a tour of the changes; why is Redis so much slower than Postgres? Marvel at the gorgeous metrics and graphs used to measure and optimize; gasp in delight as we track, live, exactly how many Heroku dynos are needed. Finally, a happy ending: today, the server responds to requests TWO ORDERS OF MAGNITUDE faster than it did before. Help us caption & translate this video! http://amara.org/v/FG9a/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
The video titled 'Deathmatch Bundler vs Rubygems.org' features André Arko discussing the challenges faced in making the bundler installation process more efficient. He narrates a significant incident where a poorly designed bundler update inadvertently led to a distributed denial of service (DDoS) attack that took down RubyGems.org. Arko recounts the journey starting from the initial release of Bundler in 2010, explaining how the introduction of bundler 1.1 aimed to improve install speeds but instead caused overwhelming server load due to increased API requests. Throughout the talk, he outlines the evolution of their strategy, addressing the following key points: - **Initial Problems**: Bundler 1.0 was slow, prompting the need for a faster API response from RubyGems.org. - **Changes Made**: The development of Bundler 1.1 brought significant speed improvements but failed to predict user behavior that would overload the server. - **System Architecture**: The importance of infrastructure is highlighted, detailing how a single VPS hosting RubyGems.org became a bottleneck. - **Performance Metrics**: Collaborating on data measurement helped to determine server response times and optimize performance with PostgreSQL and the eventual decision to turn off Redis caching due to inefficiencies. - **Scaling Solutions**: Transitioning to a standalone Sinatra app on Heroku allowed better scaling. Additionally, exploring different web servers, such as switching to Thin and later Unicorn, enhanced request handling. - **Webhook Integration**: Introducing a webhook system to synchronize updates improved reliability compared to the previous approach. - **Future Directions**: The teams are now working on a new index format for better updates which promises to further enhance performance. In conclusion, Arko presents a story of learning from failures and improving system efficiency, emphasizing the importance of community involvement in the continued development of Bundler. He expresses excitement about new initiatives and collaborations to enhance the Bundler experience.
Suggest modifications
Cancel
