For information on exhibition and sponsorship opportunities at RailsConf, contact Yvonne Romaine at firstname.lastname@example.org.
Download the RailsConf Sponsor/Exhibitor Prospectus
View a complete list of RailsConf contacts.
In his last RailsConf keynote, DHH hinted at a mechanism for Rails 3.1 for flushing partial responses out during view rendering, commonly known outside of Rails circles as “progressive rendering.” Having implemented this for Rails as a plugin, Template Streaming 1, I will present how we are using this at Patch.com, and how it changes the way you need to design parts of your application. Some key points are:
In addition, I will present how progressive rendering complements two other full-page caching techniques we use at Patch.com:
By relaxing our freshness constraints a little, these techniques can be used to ensure that for heavily trafficked pages, the initial page render is always served from a full-page cache, with user-specific data pulled in after the initial page load. Meanwhile, progressive rendering can be used to optimize pages which don’t lend themselves to full-page caching, such as search results.
George Ogata has been a Ruby enthusiast since 2001, and Rails developer since 2006. Born in Sydney, Australia, he now works for Patch.com, a network of local news sites across the United States. Patch, acquired by AOL in 2009, underwent extremely rapid expansion throughout 2010, expanding its coverage from 30 to 770 towns across 18 states. Now serving well over 5,000 requests per minute during the day, the scalability requirements have led the Patch team to explore some innovative optimization techniques in Rails such as those to be presented here.
Comments on this page are now closed.