I have a web app running on a Basic Tier with logged in users.
The web server appears to restart randomly about once a day which interrupts these users.
How can I get the web server to restart overnight instead?
Apologies it maybe be late response.
In most cases unexpected restart could happen due to unhandled exception originated in the chosen application framework (such as Python, Asp.Net, PHP etc.) and/or the application code.
Firstly, to understand why the restart occurred, you may leverage App Service diagnostics from Azure Portal> navigate to your App Service app in the Azure portal.
In the left navigation, click on Diagnose and solve problems – Checkout the tile for “Diagnostic Tools” > “Availability and Performance” > and “Web App Restarted” (to fetch more details).
To answer your question, you may create a triggered WebJob task to restart the WebApp. Is available on Basic App Service Plan.
See this doc section 'Create a scheduled WebJob' for more details.
Related
We have a web application that is using the IHostedService.
There is an example of this here
And the method we employed is detailed here
The goal was to have an application that continually ran background tasks. So we could schedule in jobs that run automatically at set times. This application is separate from all our other applications, so it's not visited by our user base.
So we needed a way for this application to run all the time on Azure.
We tried to set up an App Service for the application on Azure, but it seems that the application does not continually run. Things seem to run locally ok, but on Azure, I have to stop and restart the service before it kicks in the IHostedService tasks.
Is there a way on Azure to keep the application alive and running?
Ok, so in the App Settings in Azure, there is a setting Always On this worked for us. :)
We also found out from Azure support, that if you are on the lowest tier in their offered packages, this is treated as a "Development" environment and will only have limited up-time. As a result, we could expect the application to go offline when we reached that limit.
We argued that there should have been something more obvious in the dashboard for us to know this.
Once we upgraded to a Standard tier, the application stayed online.
Also, if you are running a hosted service and it hits an unhandled exception, this stops the service. You need to make sure you are handling exceptions for this to work.
Not sure if you are experiencing the slowness of Azure cloud web apps loading at start even though AlwaysOn has been turned on.
Looking for any idea to solve this issue.
Thanks,
Riki
As a workaround, we can create a Web Job that it will continue to call our web app according to a certain period, for example, every five minutes. By this way,our application pool is never unloaded and our site is always ready to serve users.
More information about Web JOB, we can refer to: Run Background tasks with WebJobs in Azure App Service
We can create a console application and upload it to Azure as our web job program. You can find how to do it with above documentation
Update:
As you said that you have turned on "Always-On", I guess the reason for this problem is the Recycling feature of IIS Application Pool.
We can disable it with this article: Avoid automatic recycle of Azure Cloud Services Web Role
I am running a .NET Core web application on an Azure App Service (App Service plan is configured to use S1). It is stable.
However, I recently ran an automated test against production and it caused 100s of errors in a few minutes. After this, the App Service became unavailable for a long time.
I know that App Service basically uses IIS and I know that there is a setting in IIS that will shut down an App Service on too many errors in a short time. I am assuming that this is the setting that came into effect for my app.
My question is: How do I prevent Azure from shutting down my App Service, even if many errors happen in a short time?
Investigate the "Always On" setting that can be changed in the Azure Portal under Application settings, General Settings. This value is configured per App.
The UI control will be disabled if your price tier does not support always on. Typically these lower priced levels in the pricing tiers are not used for a production site.
I recently ran an automated test against production and it caused 100s of errors in a few minutes. After this, the App Service became unavailable for a long time.
Firstly, you can enable diagnostic functionality for App Service web app to log information from both the web server and the web application, which will help you troubleshoot the issue.
Secondly, you can try to increase the number of instances that run your app and check if it can mitigate the issue.
Besides, if possible, you can set up staging environment and do automated test on staging environment instead of production environment, which will not cause your production shutting down for long time when you do automated test on staging.
I am not sure whether this problem was correctly diagnosed back in 2017 when I was using a .NET Core WebApp. Maybe it was or maybe it wasn't.
However, I have today in late 2019 on Azure Functions V2 and .NET Core 2.2 recreated the same scenario and provoked 5000 unhandled exceptions in one minute and the Function did not go down because of that.
So anyone finding this question can pretty much rest assured, if they are on Azure Functions V2 or newer - it does not crash just because of the quantity of exceptions like it was the case with default settings in IIS in the past.
For hosting one of our asp.net application, we created an Azure account which starts with a free trial. Then I created a web app from app services menu. After web app instance is deployed and ready, I clicked on the web app for changing the settings I get a window with all the menu options disabled.
Does the Azure Free trial subscription have any sort of restrictions?
A site in a free subscription is fully functional, so all this UI absolutely should be available. As you found, after creating a new site everything started working.
Now the question is what prevented this from not working in the first site. My take is that it was likely a glitch in the Azure Portal (yes, it still has a few bugs), and that a browser refresh would have solved it. If you run into this again and a Portal refresh doesn't solve it, we can investigate further.
I've recently starting experimenting with azure cloud hosting and my web app had about 10 minutes down time today.
I'm not sure why and I was wondering what tools I have available for determining the cause of the downtime.
You have application logs and site logs. Basically application logs are information produced by your web app code. You can use instrumentation to trace call and exceptions in your appliction. Site logs are information produced by the web server and you can see error messages and failed request tracing without instrumenting your code. You won't have relevant information now since by default all diagnostics are turned off but if it happens again you know where to look for.
Here's how to enable and visualize this information.
Enable diagnostics logging for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-enable-diagnostic-log/