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.
Related
I have a Node.js functions app running in azure and it is processing thousands of requests every minute, I would like to enable Application Insights using the Azure Portal in order to diagnose an issue but I fear this may interrupt the function while it configures itself.
Is this a valid concern?
All the documentation I have found regarding Application Insights does not mention the impact on any running applications.
Adding AI integration is only a matter of adding a key to app settings, but any edits to app settings require a function app to restart, so yes it will affect your function.
I did some tests, and I made a request to it after enabling Application Insights. It will indeed be affected for a few seconds because it will change the app settings and then restart the Azure function.
I am using application insight for measuring performance and also storing some telemetry data of my web application and it was working fine till last month.
But from last month I am unable to see any traffic in app insight. In last month just I have added one slot in my app service. I have checked instrumentation key, it's same and correct and there is no change in application settings and configuration in app service.
Could you please suggest me if any additional settings I need to take care ?
I suspect this issue is due to adding of slot because in other environment it's working fine.
You could go to Visual Studio configure Application Insights through there and then redeploy the application to slot.
For more information, you could refer to this doc: Application Insights support for Multiple Environments, Stamps and App Versions, , specifically the 'Multi Stamp Support'.
How are you enabling application insights for the App in Azure Web App? Are you using extensions or do you take nuget dependency at build time?
If using extension, please navigate to this url to find the status of application insights enablement: https://yoursitename.scm.azurewebsites.net/ApplicationInsights
Have you ensured that that instrumentation key is available in all slots? This is most likely an instrumentation key issue.
I am setting up a web app on Azure for which I am using an azure app service. At the moment, the app service scales down to 1 instance at night, and scales up again in the morning.
When a request is sent to the app service when there are 2 instances, the response depends on the instance which handles the request. I would expect a 200, but half of the time I get a 500 http response.
I figured out it depends on the instance because when I use a cookie ARRAffinity (which lets you choose the specific instance of the app service), I am able to reproduce always 200 reponses on 1 machine, and always 500 responses on the other machine.
WEBSITE_LOCALCACHE_ENABLED is false and hence the app service should use the same code, coming from 1 network share if I am not mistaken.
Because half of the time, the app acts normal, I think this is not a code problem, but an infrastructural problem on Azure.
The web app is written in .NET and uses .NET Core 2.2. OS Version is windows and 64 bit system.
It might be the problem with instance or it might be the problem with code. When you seen the issue try to do the Advanced restart from the portal and see if that helps.
Also during the time of the issue see Diagnose and solve problems Blade of the App service and see under Availability and Performance section for the logs information which will give better idea.
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