Videos tagged with Capacity Planning

There’s tons of information out there for Rails developers, but help for Ops teams is seemingly a bit thin. Scaling with hardware is a common approach, however hardware alone cannot scale an application. (It’s also an expensive approach.) Bayard Carlin, New Relic’s Director of Technical Operations, walks us through the steps New Relic made to tune their app servers for maximum...

Jim Gochee is the VP of Engineering at New Relic, where he’s helped shape RPM, their server monitoring tool. After asking him his recommendations for Scaling Rails, we take a closer look at some of the advanced features of New Relic’s RPM tool. If you haven’t seen some of the upper tier performance monitoring features of RPM, prepared to be impressed.

Jesse Newland works at Rails Machine, where he’s helped scale many Rails applications. In this episode we ask him for 3 tips to help us Scale our applications. We’re then going to take a closer look at one of his recommendations: how to properly deploy a Rails app.

Once you have a firm grasp of the 3 header tags we talked about in the previous episode (max-age, etags, and last_modified) you can start to take advantage of reverse proxy caches. In this episode we let you know exactly what a proxy cache is, and how you might use it to effectively scale a dynamic website to millions of users.

Once you’ve done all the server side caching you can possibly do, you might want to take a look back at the client side of things to do some advanced client-side caching.  In this episode we’ll show how to effectively use the max-age, etag, and last_modified helpers to scale your application.

Taylor Weibley is the director of support at Engine Yard, where he’s seen plenty of poorly scaling Rails applications.  In this first interview he lets us know about three things we can do today to help our application performance.  After his interview I go through some common ways to Scale your Database layer.

Most of the big Web 2.0 websites rely on memcached (pronounced "Memcache-Dee") to scale, even the ones not using Rails. In this screencast you’ll learn how easy it is to use memcached in your Rails application, and how to do low level query caching for websites where you have highly customized layouts.

If there’s no way to cache the entire content of a page, then odds are you can probably cache smaller pieces of it.  This is where fragment caching comes in, allowing you to cache common parts of a webpage which are resource intensive and may be used accross mulitple pages.

If you can’t fully page cache your Rails action, when your next best choice is using Action Caching.  Action Caching allows you to run filters such as authorization on each request before they’re able to see the cached content of the page.

Page caching is pretty simple to do, but what happens when you need pagination or dynamic data on your pages? Can you still use page caching? In this screencast we’ll start out showing how to solve these problems and finish up with my first rant of the series "Login status is overrated."