I'm trying to understand the Dyno Load section of my metrics of my app. My particular app has five worker dynos. Given that information, if I see a Load Max or Load Avg of 2 or 2.5 then I should be ok, right? With this setup my goal would be to keep the load under five (1 for each dyno)? Is that the correct way to view this?
The load you see in Heroku Metrics is per dyno. Each dyno sends its own load, the max being the maximum value.
So expecting 5 to be a good value because you have 5 dynos isn't right.
You need to evaluate that value based on the type of dynos you have, as each of them will have more CPU shares and be able to handle more load.
Heroku recommends (here) keeping Free, Hobby and Standard dynos between 0.5 and 1.0 load.
Performance-M dynos can go to 3.0 or 4.0, and PL can go up to 16.0.
See also dyno sizes and their CPU share: https://devcenter.heroku.com/articles/dyno-types
Related
I have an interrogation regarding Heroku's dynos.
As of now my app runs two 512MB dynos and I was pretty certain that this configuration, i.e. more than one dyno, ensured that the container's application was started and ready to serve clients.
However, I frequently notice that the dynos are not always started and it takes something like 8 seconds to load the app. See screen shot below. The host XXXX.herokuapp.com spends nearly 8 seconds in "waiting".
Has anyone else experienced such issues with Heroku? How can they be resolved?
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!
More dynos give you more concurrency. Based on a single threaded web server such as thin, if you have 4 x 1x dynos, you can serve four requests at the same time.
With 2 x 2x dynos you can only serve two requests.
2x dynos have more memory (1024MB) and more CPU available. This is useful if your application takes up a lot of memory. Most apps should not need 2x dynos.
Heroku have recently added PX dynos as well, which have significantly more power available.
You can read about the different dynos Heroku offers on their website.
The actual data changed since the accepted answer was posted.
The current difference is the memory (512MB for 1x and 1024MB for 2x), as well as the CPU share that is doubled for 2x.
More details can be found on the following Heroku dev center page: https://devcenter.heroku.com/articles/dyno-types
Is heroku's free 750 hours separate per app, or is it a total of 750 hours shared across all your apps?
From their site:
"Each app you create has free access to 750 dyno-hours per month and a starter-tier database."
However, from another answer on StackOverflow:
"Heroku provides, for free, 1 dyno. A dyno is an instance of your application running and responding to requests. If each instance of your application can serve each request in 100ms, then you get 600 requests/minute with the free account."
Based off of what it says there and my experience it's per app. That's talking about instances of dynos not apps. "If each instance of your application can serve each request in 100ms, then you get 600 requests/minute with the free account."
Each app you create within Heroku gets 750 dyno-hours per month for free. The number of requests your app can receive depend on the configuration of the app. For example, an app running unicorn can handle more requests than an app running something else, as unicorn can run multiple workers per dyno.
I've personally run an app on Heroku with 3 unicorn workers on one dyno, 24 hours a day, all month, and always been free (because that is ~750 dyno-hours).
I'm in development for a Rails app and I am confused about what I'm seeing. I am new to this so I may misinterpreting the information. When I run one web process I am getting good results. But when I up the web process I am not getting the results I expect. I am trying to calculate how many I will need to run in production so I can determine my costs.
Based on New Relic I have response times of 40-60 MS per request at 3000 requests per minute (or about 50 requests per second) on one Heroku Dyno. Things are working just fine and the web processes are not even being pushed. Some responses are timing out at 1 second on Blitz, but I expect because I'm pushing as much as I can through one Dyno.
Now I try cranking up the Dyno's. First to 10 then to 50. I rush with Blitz again and get the same results as above. With 50 dynos running I blitz the website with 250 concurrent users and I get response times of 2 or 3 seconds. New Relic is reading the same traffic as one dyno, 3000 requests per second with 60MS request times. Blitz is seeing 3 second response times and getting a max of 50 to 60 rps.
In the logs I can see the activity split nicely between the different web processes. I am just testing against the home page and not accessing any external services or database calls. I'm not using caching.
I don't understand why a single web process easily handle up to 60 requests per second (per Blitz), but when increasing to 10 or even 50 web processes I don't get any additional performance. I did the Blitz rushes several times ramping up concurrent users.
Anyone have any ideas about what's happening?
I ended up removing the app server, Unicorn, from my app and adding it back in again. Now I'm getting 225 hits per sec with 250 concurrent users on one dyno. Running multiple Dyno's seems to work just fine as well. Must have been an error in setting up the App Server. Never did track down the exact error though.
There are random times throughout the day that my app can have pretty extreme increases in load based on various factors.
At those times, I'd like to automatically increase the number of dynos.
I'd like to base the increase on the load time. So if it's taking X amount of time for pages to load, increase dynos. Otherwise, go back down.
Anything like that exist?
HireFire is able to auto-scale both your web- and worker dynos based on various metrics. We currently support the following metric sources/types:
HireFire (Response Time) | Web Dynos
HireFire (Job Queue) | Worker Dynos
Heroku Logplex (Response Time) | Web Dynos
Heroku Logplex (Requests Per Minute) | Web Dynos
Heroku Logplex (Dyno CPU Load) | Web Dynos
NewRelic (Apdex) | Web Dynos
NewRelic (Response Time) | Web Dynos
NewRelic (Requests Per Minute) | Web Dynos
HireFire (Response Time) performs a basic HTTP request to measure response times.
HireFire (Job Queue) allows you to auto-scale your worker dynos based on their queue-sizes. You'll setup a very simple endpoint on your end (we have a RubyGem for this, but it can be done in any language with any library very easily). We'll periodically perform checkups and scale your worker dyno formation accordingly.
New Relic allows you to integrate with New Relic. It'll periodically fetch up-to-date metric data such as Average Response Time, Requests Per Minute and Apdex to determine your web dyno formation.
Heroku Logplex is our latest addition. This approach relies on your (and Heroku's) logs. Your logs will be streamed from Heroku's Logplex to HireFire's Logdrain, where it will be parsed for metric data. This allows you to auto-scale your web dynos in a more reliable way than with HireFire/ResponseTime as it grabs data directly from Heroku's Router. This approach doesn't require any external dependencies such as New Relic either.
Get in touch if you have any questions!
There is a new plug and play addon that just launched for this: https://addons.heroku.com/adept-scale
Seems like heroku-autoscale is a good bet.