I'm running my blog on an Heroku dyno, and too many times my users have to wait almost half a minute for my blog to respond. There are ways to prevent Heroku from idling: Easy way to prevent Heroku idling? Most obvious is to ping the server every minute or so.
But it seems those methods are against Heroku's TOS, if I check the pricing page: https://www.heroku.com/pricing (see MUST SLEEP 6 HOURS IN A 24 HOUR PERIOD). And because Pingdom does costs me some money as well, I'm thinking of paying $7 dollars a month for the Hobby package. But how many apps can you run with that package? Cause I always run one app per dyno, but if I have to pay $7 per app... That seems too much.
Anyone who knows there is a way to run multiple apps on a dyno? Or is hiring a server at DigitalOcean with NodeJS a better choice, for example?
The free and hobby dyno types only support a maximum of one dyno running per process type. Additionally, applications using a free dyno type are limited to a maximum of two concurrent running dynos.
By default, a process type can’t be scaled to more than 100 dynos for standard-1X or standard-2X sized dynos. A process type can’t be scaled to more than 10 dynos for performance dynos.
Related
So, after my research on stackoverflow and other portals, I have not found any answer to the below question.
I am using a free Heroku account without any kind of payments. If I run, say 2, applications on the free account, does it mean that I am using 2 dynos. Because I know that two dynos will consume double the dyno hours(If both the applications never sleep. I am aware of these basics of Heroku), and so this is a concern for me.
Since only one free dyno is available. How many users can simultaneously run my application?
And how does it calculate how many free dyno hours have been used
As Dominic mentions in the comments, this will depend heavily on how your application is architected -- what web server it's using, how quick responses can be returned, etc.
From the "Free dyno hours" perspective, the clock is ticking whenever the dyno is up and running. After 30 minutes of no activity, the dyno will idle and the clock will stop ticking. You can read more about this here: Free Dyno Hours
Heroku reboots servers everyday. After reboot, my node server takes around 20 seconds to load a page for the first time. Is there a way to prevent this?
EDIT: You guys seem to be misunderstanding the situation. In Heroku, even production servers must be restarted daily. This is not the same as a free server sleeping. This question is aimed more at preventing lazy-loading and pre-establishing connection pools to databases.
Old question, but in case others stumble upon it like I did
Use can use Heroku's Preboot feature:
Preboot changes the standard dyno start behavior for web dynos. Instead of stopping the existing set of web dynos before starting the new ones, preboot ensures that the new web dynos are started (and receive traffic) before the existing ones are terminated. This can contribute to zero downtime deployments
You could also combine it with a warmup script like the one described in this Heroku post
I have currently a node.js app deployed on a free web Dyno running on Heroku. As planning to make it production, I need to think about a redundancy and failover solution at a reasonable cost.
As I ran "Prodiction Check" on the Heroku Dashboard, it gave me a list of things to do to make it production. One of the things is "Dyno redundancy" that I should have at least 2 web dynos running for failover. Does it mean I should upgrade my Free Dyno to Hobby or Standart 1X, and should I also need to have two dyno of the same type, e.g. two Hobby dynos or two Standard 1X dynos?
How does Heroku handle failover from one Dyno to another one?
Thanks!
Heroku shares traffic between all available dynos, distributing requests using a random assignment algorithm. So all your dynos will always be serving incoming traffic.
This provides redundancy, not failover. If one dyno is choking on a very slow request, the app will still be available via the other dynos.
Failover is different. In the case of an application failure (say, the database is inaccessible) Heroku's router offers little help. To deal with more industrial workloads, you could use Amazon Route 53's DNS-level failover, which runs a health check against the backend and will reroute the domain name in the case of a Heroku crash.
However for many use-cases it is probably enough to simply offer a friendly, customised HTTP 503 error page, which you can configure in Heroku, to keep users happy during an outage.
I have a service that I run daily in the background with a database of about 140mb in size. The calculations I run require me to load all 140mb into Node at once, and after a minute or so quickly reach the process limit of 512mb and Heroku restarts the process.
For the mean time, a quick solution is to increase the server to 2X so I get 1 GB RAM, but within a month or so the database will outgrow that as well.
As far as Heroku goes, is my option basically to upgrade Dyno options? Since these are calculations I do once per day, I would rather run them locally on my machine and upload the results than to pay $250-500/month for the Performance Dynos.
I know I could also just upgrade to the Performance Dynos to run these services and then downgrade once finished, but I'm looking for something I can automate and not have to deal with each day.
Thanks for reading.
Heroku Scheduler seems to fit your use case exactly. You can schedule your task to run daily on a One-Off Dyno of any size, and since Heroku pricing is "prorated to the second" you will only pay for the time that your task is running on that Dyno.
I haven't actually used this, but I was about to recommend a similar solution on AWS when I searched and found this feature of Heroku.