I need to wake the backend free Heroku app at the same time as my frontend Heroku app.
When I visit my frontend application running React it takes about 15 seconds to wake up but then another fifteen seconds after the first API call for my backend to wake up. Is there a way to link these two so they wake up at once? I know I could put a call to the backend on first load of my site but that would still take the backend longer to wake up.
Is there a way to link these two so they wake up at once?
No.
Related
I plan to deploy a mini web app to resize photos to the heroku free tier. I read that the heroku file system is ephemeral - uploaded files get deleted when the dyno restarts. What I want to know is if I upload an image only for a short duration to change its properties and then download it, is there a chance that it will get deleted before I download it? That is, can the app get cycled when it is in use?
Regards,
Debashish
On a free tier a web dyno gets cycled on:
1) Dyno restarting - according to the documentation
Dynos are also restarted (cycled) at least once per day to help maintain the health of applications running on Heroku. Any changes to the local filesystem will be deleted. The cycling happens once every 24 hours (plus up to 216 random minutes, to prevent every dyno for an application from restarting at the same time).
Restart can happen at any time then, when occurring, also in progress web request could be terminated. After the restart is triggered, you have 30 seconds to graceful shutdown before the process gets killed
2) Dyno sleeping - according to the documentation
If an app has a free web dyno, and that dyno receives no web traffic in a 30-minute period, it will sleep
If your web request executes during the same session all the operations to upload/change/download the image, you should be guaranteed the file does not get deleted in the process. However, you can avoid these events using monitoring services such as Pingdom or New Relic that can prevent a web dyno from sleeping
I'm creating a chatbot with dialogflow and I have a webhook hosted on heroku (so that I can use python scripts). The webhook works fine most of the time. However when I haven't used it in a while it will always fail on the first use with a request timeout. Has anyone else come across this issue? Is there a way to wake up the webserver before running the script I have written?
Heroku's free dynos will sleep after 30 minutes of inactivity.
Preventing them from sleeping is easy. You need to use any of their paid plans.
See https://www.heroku.com/pricing
Once you use a Hobby dyno, your app will never sleep anymore and you shouldn't be getting request timeouts.
Alternatively, you can also benchmark what's taking a long time to boot your app. With a faster boot time, the first request would be slow but wouldn't get a timeout.
Heroku times out requests after 30 seconds.
When I try to access https://boiling-bastion-xxxx.herokuapp.com/, it takes about 5 seconds or more to load. Is that normal?
Once it loads, it runs fine. I'm talking about actually accessing the link for the first time. Is this the same for others as well?
Yes, this is completely normal.
There's information about it on devcenter.heroku.com: https://devcenter.heroku.com/articles/dynos#dyno-idling
If your application has one hour of inactivity your web dyno will idle out. If you access your application after one hour the web dyno will wake up again, causing a few seconds of delay.
Important:
This is only a problem when you have one (free) web dyno. If you have more then 1 web dyno running you will never face these troubles.
I currently have an app deployed on Heroku which runs on two web dynos so it won't go to sleep if it remains inactive for a certain time.
Now if I scale it down to only one web dyno (free) and instead pay for one worker dyno, will Heroku always keep my app active?
It will still idle - you NEED to have more than a single web dyno
https://devcenter.heroku.com/articles/dyno-idling
You can also use the New Relic add-on to monitor your app and keep it alive. There is a tab in settings to configure availability monitoring.
You can also avoid a single web dyno from idling by using a monitoring service like pingdom.com since it's periodically sending a request to your web dyno.
Try Pingdom. Free plans include one website check. I use this service to keep my app active all the time.
Pingdom tests your websites and other infrastructure components as
often as every minute to make sure it is all up and running.
From Pingdom Homepage
Pingdom does this by "pinging" or rather requesting a resource from your website on a regular interval. This has the side effect of keeping your website "active", cache's primed, etc.. because your website is seeing regular "traffic" (the requests coming from pingdom).
Try Un-idler. You don't need to sign in and it's free.
http://unidler.herokuapp.com/
You can try http://kaffeine.herokuapp.com/ it will ping your app every 30 minutes so your app won't go to sleep.
Try CloudUp. It visits your apps periodically to keep them awake. It is free, and you can add as many apps as you want. It also activates apps on Google App Engine and Azure.
I have a Windows Azure hosted MVC3 application. In the Application_Start, I call all of my bootstrappers that need to run before the application loads and that is working great. One of the bootstrappers that runs, hits up some web service APIs to preload and cache a bunch of data. This process can take 10-15 seconds which is fine because it's in Application_Start and is a one time hit after I deploy and hit up the site myself.
The site isn't launched yet and I've found that once I deploy and click around for a bit everything is fine and really quick, then if I leave the site alone for 45 mins or so and go back to it, there is a long delay when loading the page. Through logging I've found that the Application_Start is getting fired and I'm having to wait for the site to fire back up and run all my bootstrappers.
My question is, is it normal for an Azure WebRole to "go to sleep" if there is inactivity? And if so, how can I stop that from happening so that my lucky user that accesses the site that time doesn't have a long wait time and bad experience.
By default, IIS has a 20-minute timeout on idle applications before it unloads them. Consider using a startup task to disable this timeout: http://blog.smarx.com/posts/controlling-application-pool-idle-timeouts-in-windows-azure.