Heroku's killer feature has always been its ability to easily scale up and scale out our applications as our user base grows. This frees us from the pains of setting up and managing load balancers and additional servers on our own. In this recipe, we will be introduced to Heroku's dynos and workers as well as learn how to scale them both up and out as our applications grow.
Dyno is the term Heroku uses for its web servers. A dyno is simply a virtual private server that runs our application and responds to web requests.
Heroku has an additional class of servers known as workers. These are identical to dynos, with the exception that they do not serve web requests.
Both dynos and workers are available in three different sizes: 1X, 2X, and PX. The default size is 1X; this is a small virtual server with 512 MB of RAM. These are large enough to run most web applications. However, if we find that our application is constrained by the limited memory or CPU size, we can scale up our dynos up to 2X, which provides 1024 MB of RAM and twice as much computing power.
Note
If our application has only a single 1X dyno running, it will shut down after an hour of inactivity. To avoid this, we need to have at least two dynos running or use a single 2X dyno.
The largest process size is the PX or performance dyno. These are dedicated virtual servers that do not share resources with any other Heroku customers. They have 6 GB of RAM and 40 times the compute resources of the standard 1X-sized dyno. Performance dynos should only be considered for applications that have high memory and CPU requirements.
We'll use the Heroku CLI for this recipe. Let's open up a terminal and navigate to a directory with one of our existing Heroku applications and perform the following steps:
To view our currently running processes, we can use the
pscommand. It will show the type, the size, and exactly what's running:$ heroku ps === web (1X): `bundle exec unicorn -p $PORT -c ./config/unicorn.rb` web.1: up 2014/03/15 19:41:27 (~ 8s ago)
We currently have only one dyno running for this application. Let's scale it up to two; this will effectively double our application's capacity. Scaling processes are done with the
ps:scalecommand:$ heroku ps:scale web=2 Scaling dynos... done, now running web at 2:1X.
The
scalecommand is very flexible. If we want, we can scale both dynos and workers at the same time:$ heroku ps:scale web=2 worker=1 Scaling dynos... done, now running worker at 1:1X, web at 2:1X.
We can change the size of our dynos using
ps:resize. Let's scale up our web dynos to 2X:$ heroku ps:resize web=2x Resizing and restarting the specified dynos... done web dynos now 2X ($0.10/dyno-hour)
We can also scale and change the size in the same command. Let's dial our dynos back down to one and adjust the size to 1X:
$ heroku ps:scale web=1:1x Scaling dynos... done, now running web at 1:1X.
To finish up, we can scale our workers back down to zero:
$ heroku ps:scale worker=0 Scaling dynos... done, now running worker at 0:1X.
Now that we have learned how to scale our applications, let's go a little more in depth to learn about the different types of Heroku dynos.
A dyno is simply a web server. When we create our application's Procfile, the web process that we define is what runs on our dynos. When a user visits our web application, their requests get sent to our dynos via Heroku's routing layer. The routing layer acts like a load balancer. It distributes our users' requests and monitors the health of our dynos. To handle more users, we can scale out our application by increasing the number of running dynos. This allows us to serve requests from more concurrent users. If we are currently running one dyno and adding another, we have theoretically doubled the amount of web requests that our application can respond do.
In our Procfile, any process other than web will run on a worker. Workers are used to process background tasks such as sending out e-mails or generating PDFs. Any task that a user should not have to wait for is a good candidate that will run on a worker. For a Rails application, any background job (such as Resque or Sidekiq) will need to be run on a worker dyno. Workers can be scaled in exactly the same way as dynos. If our application has a large backlog of tasks that need to be completed, we can add additional workers to increase the number of tasks we can complete simultaneously.
To learn more about scaling, take a look at Chapter 6, Load Testing a Heroku Application