All posts tagged with performance


Last year, we launched the original Performance dyno, designed to support the largest apps running at-scale with more consistent service and faster response times. Today, with the goal of continuing to support our fast growing customers with more flexibility to choose the type of dynos best for their applications, we are excited to announce improvements to our performance dyno lineup:

  • Performance-L — an improved and more powerful version of the existing Performance dyno, renamed the Performance-L dyno
  • Performance-M — an entirely new dyno and smaller sibling to the Performance-L dyno

The Performance-L dyno now has 14GB of RAM, 133% more RAM than the previous version, answering a request...

In a recent patch we improved Rails response time by >10%, our largest improvement to date. I'm going to show you how I did it, and introduce you to the tools I used, because.. who doesn’t want fast apps?

In addition to a speed increase, we see a 29% decrease in allocated objects. If you haven't already, you can read or watch more about how temporary allocated objects affect total memory use. Decreasing memory pressure on an app may allow it to be run on a smaller dyno type, or spawn more worker processes to handle more throughput. Let's back up though, how did I find these optimizations in Rails in the first place?

A year ago Heroku added metrics to the application...

Working with our support team, I often see customers having timeout problems. Typically, their applications will start throwing H12 errors.

The decision to timeout requests quickly wasn't made to avoid having long-running requests on our router, nor to only have fast apps on our platform, but because standard web servers do not handle these types of requests particularly well.

Performance is important, and if we can't measure something, we can't make it fast. Recently, I've had my eye on the ActionDispatch::Static middleware in Rails. This middleware gets put at the front of your stack when you set config.serve_static_assets = true in your Rails app. This middleware has to compare every request that comes in to see if it should render a file from the disk or return the request further up the stack. This post is how I was able to benchmark the middleware and give it a crazy speed boost.

Flow is an important part of software development. The ability to achieve flow during daily work makes software development a uniquely enjoyable profession. Interruptions in your code/test loop make this state harder to achieve. Whether you are running unit tests locally, launching a local webserver, or deploying to Heroku there's always some waiting and some interruption. Every second saved helps you stay in your flow.

We’ve been working on reducing the time it takes to build your code on Heroku. Read through this post for details on the process we used to make builds fast, or check out the end result from the graph below:

heroku_build_speed@2x

Let's take a look at our process in delivering these...

Browse the blog archives or subscribe to the full-text feed.