Is it possible to disable worker Dynos in between specific hours? I'd like to do this to keep my free dyno hours for a Discord bot, which will not be used between 1:45 AM and 8:30 AM.
Heroku has a public API: https://devcenter.heroku.com/articles/platform-api-reference
You can use that API to update your dyno formation, increasing or decreasing the number of workers.
So, while this isn't offered as an Heroku feature, you can write code which will do it for you. Using Heroku's Scheduler, you could get a dyno which will run at regular intervals, and decide whether it needs to bring your worker on or off.
Related
I recently finished making a discord bot and am ready to push it to production. I need to use 2 dynos, one is a worker (node index.js) and the other is a web worker. Because I am using two dynos, are double my dyno hours used or are the dyno hours calculated across the whole app? I ask because I want to use the free 550-1000 hours per month.
I have deployed my node app on heroku free web dyno plan.I want to know how much free hours are remaining and how much are left so for that I am using
heroku ps -a <AppName>
After running above command I got something like this below:
As per the result everything is clear but what does Web(Free) mean written in green color. Someone please let me know any help would be appreciated.
THANKS
It means your app is running on a single web dyno and free dyno type.
Dyno configurations
Every dyno belongs to one of the three following configurations:
Web: Web dynos are dynos of the “web” process type that is defined in your Procfile. Only web dynos receive HTTP traffic from the routers.
Worker: Worker dynos can be of any process type declared in your Procfile, other than “web”. Worker dynos are typically used for background jobs, queueing systems, and timed jobs. You can have multiple kinds of worker dynos in your application. For example, one for urgent jobs and another for long-running jobs. For more information, see Worker Dynos, Background Jobs and Queueing.
One-off: One-off dynos are temporary dynos that can run detached, or with their input/output attached to your local terminal. They’re loaded with your latest release. They can be used to handle administrative tasks, such as database migrations and console sessions. They can also be used to run occasional background work, as with Heroku Scheduler. For more information, see One-Off Dynos.
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.
Dyno Types
Heroku provides a number of different dyno types each with a set of unique properties and performance characteristics. Free, Hobby, 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.
I'm testing an app with a worker and a web dyno on Heroku free tier and I'd like to keep the worker alive to be able to execute background tasks while letting the web dyno idle. By default they both go idle in 30 mins even if I have things queued on the worker.
I understand there're ways to keep the web dyno alive (and with that the worker as well), and there're ways to keep the web alive while scaling down the worker. However I'd need the worker alive and the web in idle.
I tried running a recurring job on the worker which would
Restart the dyno.
Scale the dyno down and then back up.
Both approaches worked (as in they restarted and scaled the dyno correctly) but the worker dyno would still idle after 30 mins (as if it's dependent on the web dyno). Edit: yep, that's pretty much the case as explained here: https://devcenter.heroku.com/articles/free-dyno-hours#dyno-sleeping
I could do this form the outside but it seems I'd have to constantly check for the state since a new restart doesn't seem to give me 30 mins headway. I'd also have to expose the API key which I'd like to avoid.
If I've gotten you right, you're trying to stop the web dyno and leave the worker dyno alive.
You could do that by going to the Resources tab:
And then in the 'web' section:
Press the pencil, toggle it off and press 'Confirm'.
As a workaround I currently remove the web dyno and explicitly enable it when I need it. As explained here:
Worker-only Free dynos do not sleep since they do not respond to web
requests.
My workaround was to just create two apps that deploy automatically from the same repository. Then, all you would need to do is enable the worker dyno for one and the web dyno for the other.
Very similar question to Is it feasible to run multiple processeses on a Heroku dyno?, or Running Heroku background tasks with only 1 web dyno and 0 worker dynos except I'm talking about a Ruby on Rails app.
Context:
I understand that it's encouraged to separate worker and web dynos... but I'm still testing and don't want to pay the expense. Especially because with my app, all the web requests pretty much happen either in the AM or in the PM, and during the whole middle of the day (and also middle of the night), literally nothing is happening.
I'd like the web dyno to run two types of background processing on the "downtime":
A recurring, long-running task every day (mailings)
An asynchronous, long-running task that is triggered when a user performs a certain action (it's a mailer)
I've done quite a bit of reading on this, but this is my first time doing anything asynchronous, so I wanted to ask the community a couple of questions just to ensure what I'm trying to do is feasible.
Questions
How do I do activity #1 for free?
To put it bluntly... considering my context above, if I use Heroku's Scheduler add-on, this runs a one-off dyno which I'll be charged for since I use NewRelic now to constantly ping my web dyno so it never actually sleeps meaning my one web dyno is my free dyno. Is there another way of doing this with the one web dyno that, in the middle of the night, won't be processing any requests? Alternatively, is there a way to tell New Relic to ping except at certain times, which will also then allow me to spin up a one-off dyno but still be within my free dyno hours?
For activity #2, I'm thinking of using Delayed Jobs, but how do I tell Delayed Jobs to delay until end of user 1's session, and then run mailer for user 1, but then pause again if user 2 sends a request, and then when user 2 is finished, start where left off on user 1's mailer, and then do user 2's mailer... and so forth? I think the root of the challenge here is that from what I've read, Delayed Jobs needs to be started with a script. But I'm not going to be at my computer starting a script all the time. How do I make the start (and the queue as illustrated in the question) something that happens automatically?
Would love even just point me directional pointers on what methods/ what considerations, etc.
I'm going to check out a nifty gem https://github.com/brandonhilkert/sucker_punch to do this. According to the author, it was written specifically to use Heroku's single dyno for hobby websites that have no need to spin up another dyno. It basically creates another thread.
FYI also, there is an add-on link that allows sucker_punch to do recurring tasks, called https://github.com/facto/fist_of_fury
My understanding is that Heroku charges Cron tasks based on the actual amount of time the task runs, using a dyno (based on: https://devcenter.heroku.com/articles/scheduler#dynohour-costs).
So, if I need a quick task to run every X minutes, I could use the cron addon to process it, instead of a worker dyno and I would be charged a fraction of the cost.
So, if everything above is true, what is the use of the Iron.io workers? They charge (about) the same as dynos from the cron jobs and they can't connect to the DB.
I have a feeling that I am missing something.
I'm under the impression that IronWorker can use the databases for Heroku. I may be mistaken about this, however.
I can't claim a great deal of experience with cron tasks on Heroku, so forgive me if I get its limitations wrong. However, I'm under the impression that scaling from one dyno to many dynos is a little bit of a process. Where IronWorker shines is really in enabling the number of worker servers to fluctuate based on demand--you have the capacity to scale at a moment's notice, but are only paying for the scale you're actually using.