I have a web role in azure that is using syncfusion docToPdf to convert word documents to pdf.
If I publish this role using a full deployment, converting a doc is fast, <500ms.
But after a update deployment, it's unusable slow, >5s every time.
If I reimage the instance it will be fast again, until I do a new deployment update.
If I reboot the slow instance it has no effect.
For all other functionality in the role there is no performance difference between full deployment and upgrade deployment.
I do not understand why this is happening or where to start to fix it...
It turns out that this happened because of Application Insights, for some reasons it made word to pdf 10 times slower.
When we modified applicationinsights.config and replaced [All Namespaces] with only our own namespaces syncfusion started running smoothly again
Windows Azure cloud service take some amount of time to initiate the service while accessing it first time, immediately after update deployment. This is due to the cloud service stops from the server when the service is idle for a certain amount of time, while updating the cloud service. Whereas the service remains running immediately after full deployment, hence it doesn’t require to restart service. Please refer the below blog for further details
http://wp.sjkp.dk/windows-azure-websites-and-cloud-services-slow-on-first-request
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.
i run a azrue webrole (hosts 2 websites + 1 webservice) which was originally uploaded in that mentioned "package".
After the initial upload I published some hotfixes of one of the websites via Web Deploy.
If my azrue role restarts (of whatever reason) the updated sites falls back to the version the role was originally uploaded with.
Is that intended? Is there some way to prevent this? I can't find any information on that topic :(
Thanks for your help!
If my azure role restarts (of whatever reason) the updated sites falls
back to the version the role was originally uploaded with.
Is that intended?
Yes. Any changes done to the website after the package is published will be rolled back in case Azure decides to tear down the role and put it in another VM. This is because Azure Cloud Services (Web/Worker role) are stateless. However this should not happen when a role restarts (or in other words reboots).
Is there some way to prevent this?
Unfortunately no. If you want to make your changes persistent, you will have to update the deployment by uploading a new package.
Would like to know how can i upgrade a single role of deployment application on hosted service using REST API.let say I have 2 web and 1 worker role and i would like to update/upgrade only one webrole out of 2 .I know that we can do it Azure Management Portal.
Would also like to know how rollback works in Azure.If I like to rollback deployment application to previous state, can i rollback?
You cannot modify the number of roles using the Service Management API. This is only possible by doing a new deployment (this is possible using the API).
The only thing you can do is modifying the number of instances by using the ChangeConfiguration request: Change Deployment Configuration
Rolling back a deployment to a previous state is possible using the REST API. What I tend to do when deploying a new version is by using a VIP swap:
I deploy the new version of my app to staging
I do a VIP swap (new version becomes production, old version becomes staging)
I shut down the staging version (without deleting it), this way the old version stops processing messages from queues etc.. in case my logic changed.
If I want to roll back, I simply turn the old deployment back on and do a VIP swap again. This way of working comes with 2 remarks:
You can only "revert" to the previous version of your app
You need to take into account that you might have changed external resources (like SQL Azure) and rolling back the application could break because of this change
Edit: Modified my rolling back answer with a link to the REST API
Good answer by #Sandrino. Just wanted to expand on in-place updates a bit. The Upgrade Deployment REST API call is what you'd use for updating a role. As Sandrino pointed out, you'll still need to push a new deployment package up (which includes all roles), but you can then specify to upgrade only a single role from the entire package by specifying the role name for the RoleToUpgrade element.
See this MSDN reference article on the Upgrade Deployment API call.
EDIT: All REST APIs are also available through PowerShell cmdlets (downloadable here). Take a look at Set-AzureDeployment, which has an Upgrade parameter set.