Dynos Pack
Owoeye Heatley
Dynos are the building blocks that power any Heroku app, from simple to sophisticated. Deploying to dynos, and relying on Heroku's dyno management, makes it easy for you to build and run flexible, scalable apps - freeing you from managing infrastructure, so you can focus on building and running great apps.
I created a Heroku app from an existing Python (Pyramid) project. All the dependencies appear to install correctly. I created a Procfile that specifies a web dyno, and it runs fine locally with foreman. However, when I deploy, no web dynos launch. This is verified in the logs. The Heroku dashboard also lists no dynos at all for this app.
Just to explain: Procfile only specifies the "types" of dynos your app has, not how many of each you need. You need to scale up by either running heroku ps:scale web=1 to by doing it from the dashboard.
Once a web or worker dyno is started, the dyno formation of your app will change (the number of running dynos of each process type) - and subject to dyno lifecycle, Heroku will continue to maintain that dyno formation until you change it. One-off dynos, on the other hand, are only expected to run a short-lived command and then exit, not affecting your dyno formation.
The dyno manager keeps dynos running automatically; so operating your app is generally hands-off and maintenance-free. The Common Runtime has a single dyno manager per region that is responsible for managing all dynos across all tenants running in a region. The Private Spaces Runtime has a dedicated dyno manager per space. This dyno manager only manages dynos that run within the space
Heroku provides a number of different dyno types each with a set of unique properties and performance characteristics. Eco, Basic, Standard and Performance dynos are available in the Common Runtime to all Heroku customers. Private Dynos only run in Private Spaces and are available in Heroku Enterprise.
To scale horizontally (scale out), add more dynos. For example, adding more web dynos allows you to handle more concurrent HTTP requests, and therefore higher volumes of traffic. For more information, see Scaling Your Dyno Formation.
To scale vertically (scale up), use bigger dynos. The maximum amount of RAM available to your application depends on the dyno type you use. For more information, see Dyno Types for Common Runtime and Heroku Enterprise for Private Spaces.
Applications with multiple running dynos will be more redundant against failure. If some dynos are lost, the application can continue to process requests while the missing dynos are replaced. Typically, lost dynos restart promptly, but in the case of a catastrophic failure, it can take more time. Multiple dynos are also more likely to run on different physical infrastructure (for example, separate AWS Availability Zones), further increasing redundancy.
All dynos are strongly isolated from one another for security purposes. Heroku uses OS containerization with additional custom hardening to ensure that access is properly restricted for all customers.
Eco, Basic and Standard dynos, even though completely isolated, may share an underlying compute instance. Heroku employs several techniques to ensure fair use of the underlying resources. However, these dyno types may experience some degree of performance variability depending on the total load on the underlying instance.
Performance and Private dynos do not share the underlying compute instance with other dynos. Therefore, these dyno types are not only more powerful but also experience low variability in performance. In addition to having dedicated compute resources, Private dynos are furthermore isolated in their own virtual network determined by the Private Space they are deployed in.
The Common Runtime provides strong isolation by firewalling all dynos off from one another. The only traffic that can reach a dyno is web requests forwarded from the router to web processes listening on the port number specified in the $PORT environment variable. Worker and one-off dynos cannot receive inbound requests.
Dynos in a Private Space are all connected via a virtual private network configured as part of the space. Add-on data services installed in the space are also connected to this network. Similar to the Common Runtime, web processes can receive web requests by listening on the port number specified in the $PORT environment variable. In addition, any process in a dyno can choose to listen on a port number of choice and receive connections from other dynos on the private network. This is supported for web, worker and one-off processes.
* Running ps:stop on dynos that are part of a scaled process will automatically be restarted. In Private Spaces, ps:stop will terminate and replace the dedicated instance running the dyno(s). To permanently stop dynos, scale down the process.
For most purposes, config vars are more convenient and flexible than .profile. You need not push new code to edit config vars, whereas .profile is part of your source tree and must be edited and deployed like any code change.
The $DYNO variable value is not guaranteed to be unique within an app. For example, during a deploy or restart, the same dyno identifier could be used for two running dynos. It will be eventually consistent, however.
After the .profile script is executed, the dyno executes the command associated with the process type of the dyno. For example, if the dyno is a web dyno, then the command in the Procfile associated with the web process type will be executed.
These limits include all processes and threads, whether they are executing, sleeping or in any other state. Note that the dyno counts threads and processes towards this limit. For example, a standard-1x dyno with 255 threads and one process is at the limit, as is a dyno with 256 processes.
If your application requires more time to boot, you may use the boot timeout tool to increase the limit. However, in general, slow boot times will make it harder to deploy your application and will make recovery from dyno failures slower, so this should be considered a temporary solution.
In addition, dynos are restarted as needed for the overall health of the system and your app. For example, the dyno manager occasionally detects a fault in the underlying hardware and needs to move your dyno to a new physical location. These things happen transparently and automatically on a regular basis and are logged to your application logs.
When the dyno manager restarts a dyno, the dyno manager will request that your processes shut down gracefully by sending them a SIGTERM signal. This signal is sent to all processes in the dyno, not just the process type.
The application processes have 30 seconds to shut down cleanly (ideally, they will do so more quickly than that). During this time they should stop accepting new requests or jobs and attempt to finish their current requests, or put jobs back on the queue for other worker processes to handle. If any processes remain after that time period, the dyno manager will terminate them forcefully with SIGKILL.
Our process ignores SIGTERM and blindly continues on processing. After 30 seconds, the dyno manager gives up on waiting for the process to shut down gracefully, and kills it with SIGKILL. It logs Error R12 to indicate that the process is not behaving correctly.
Using a dyno type that is too small might cause constant memory swapping, which will degrade application performance. Application metrics data, including memory usage, is available via the Metrics tab of the Heroku Dashboard. You can also measure memory with log-runtime-metrics. Memory usage problems might also be caused by memory leaks in your app. If you suspect a memory leak, memory profiling tools can be helpful.
Swap is not available on all dynos in Private Spaces, e.g. Private-M. Dynos vastly exceeding their memory quota typically emit R15 errors (although the platform may drop R15 errors in some cases), but do not use swap space. Instead, the platform kills processes consuming large amounts of memory, but may not kill the dyno itself.
A single-threaded, non-concurrent web framework (like Rails 3 in its default configuration) can process one request at a time. For an app that takes 100ms on average to process each request, this translates to about 10 requests per second per dyno, which is not optimal.
Single threaded backends are not recommended for production applications because of their inefficient handling of concurrent requests. Choose a concurrent backend whenever developing and running a production service.
Multi-threaded or event-driven environments like Java, Unicorn, EventMachine, and Node.js can handle many concurrent requests. Load testing your app is the only realistic way to determine request throughput.
Does anyone know the answer for this? I spawned two 2X dynos on heroku and the performance with the free 1X dyno is much better than the two 2X dynos. They both have the same Rails app talking to the same database. Boggles my mind!
In recent weeks' posts, I have been making changes to my personal project EffectiveDonate, including making my React components responsive, optimizing the site for mobile, and improving the UX. All of these changes have been getting me closer to considering EffectiveDonate "production ready".
However one barrier that has stood in the way of production had to do with my settings on Heroku. Heroku is the cloud application platform that I have been using to deploy my web development projects, including EffectiveDonate. The particular problem that I faced had to do with a concept called "dynos" in Heroku, which are the building blocks powering any Heroku app. In this post, I will explain what dynos are, the problem that affected my website, and how I fixed it.
To understand dynos, we must first learn about the concept of containerization in app development. Containerization is what abstracts away the need for app developers to manage hardware or virtual machines. Instead, we just deploy the app to a cloud platform like Heroku, which package the app into containers, which are environments that provide compute, memory, an OS, and a file system.
64591212e2