Search overlay panel for performing site-wide searches

Build Your Next Big Thing on Heroku. Sign Up Now!

Engineering

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.

[Heroku Connect] [heroku_connect] is written primarily in Python using Django. It’s an add-on and a platform app, meaning it’s built on the Heroku platform. Part of our interface provides users with a realtime dashboard, so we decided to take advantage of socket.io and node.js for websocket communication. But like all Heroku apps, only one type of dyno can serve traffic. This left us with two choices: manage 2 apps, each with its own repo, and carefully consider when and how we deployed them, or find a way to serve both node and Django traffic from the same app.

Heroku provides many instrumentations for your app out of the box through our new Heroku developer experience.

We have open-sourced some of the tools used to instrument Heroku apps, but today’s focus will be on instruments, a Go library that allows you to collect metrics over discrete time intervals.

With the Salesforce hackathon fast approaching, I wanted to give a quick overview on building apps that use the force.com APIs (part of the Salesforce1 platform).

The force APIs are rich and varied, so sometimes just getting started can seem a little daunting.

One of the challenges when starting a mobile app project is deciding what technology stack to use. Should the client app use iOS or Android native, mobile web, or a hybrid? Do the backend in Node, Ruby, or Java? Or skip the backend and use an Mobile Backend-as-a-Service?

To help avoid needing to answer all those on your own we are open sourcing the Heroku Mobile Template. This app provides a full-stack starting point for creating new hybrid mobile apps and deploying them to Heroku.

The Heroku Routing team does a lot of work with Erlang, both in terms of development and maintenance, to make sure the platform scales smoothly as it continues to grow.

Over time we’ve learned some hard-earned lessons about making systems that can scale with some amounts of reliability (or rather, we’ve definitely learned what doesn’t work), and about what kind of operational work we may expect to have to do in anger.

This kind of knowledge usually remains embedded within the teams that develop it, and tends to die when individuals leave or change roles. When new members join the team, it gets transmitted informally, over incident simulations, code reviews, and other similar practices, but never in a really persistent manner.

For the past year or so, bit by bit, I’ve tried to grab the broad lines of this knowledge and to put it into a manual, that we’re proud to release today.

Celery is by far the most popular library in Python for distributing asynchronous work using a task queue. If you’re building a Python web app, chances are you already use it to send email, perform API integrations, etc. Many people choose Redis as their message broker of choice because it’s dead simple to set up: provision a Redis add-on, use its environment variable as your BROKER_URL, and you’re done. But the simplicity of Redis comes at a cost. Redis does not currently support SSL, and it doesn’t seem like that’s going to change any time soon. Because Heroku add-ons communicate over the public web, that means the contents of Celery jobs are traveling unencrypted between dynos and Redis.

Many of Heroku's internal components make heavy use of logfmt to log information about what's going on in production. The format is hugely valuable in that it allows us to retroactively analyze what happened during any arbitrary request to our components, query our log traces in very flexible ways, and combined with Splunk, easily generate arbitrary metrics on historical data. It's unquestionably been an invaluable tool for fixing countless bugs, tracking down the root cause of many production incidents, and assessing usage in ways that would have been difficult otherwise.

Retrospectives are a valuable tool for software engineering teams. Heroku consistently uses retrospectives to review operational incidents, root cause problems, and generate remediation tasks to improve our systems. Increasingly we use retrospectives for another purpose: to improve teamwork and interactions on projects. Here we intentionally avoid technical discussions and focus on the emotional and human aspects of work, with the goal of creating positive insights into how to improve as a team.

Heroku Connect is a service offered by Heroku which performs 2-way data synchronization between Salesforce and a Heroku Postgres database.

When we first built Heroku Connect, we decided to use polling to determine when data had changed on either side. Polling isn’t pretty, but its simple and reliable, and those are “top line” features for Heroku Connect. But polling incurs two significant costs: high latency and wasted resources. The more you poll the more you waste API calls and database queries checking when there are no data changes. But if you lengthen your polling interval then you grow the latency for the data synchronization.

Subscribe to the full-text RSS feed for Engineering.