This is something that I had to do with some client, so let’s start with the basics:
What is “Azure App Service Local Cache”?
Local Cache is like a temporary area where the App service can store all the content related to the App Service. So, instead of referring a shared location, the App Service stores all its content in each provisioned VM.
If the App Service is being configured in 2 VMs, all the content would be copied in both the VMs. As you can imagine, reading the content from the local copy is better than reading them from a shared location and as a result, there would a bit of improvement of the performance when we enable the “App Service Local Cache” feature.
So, in simple words, Azure App Service Local Cache is a copy of all the content located in “Site” and “Site Extensions” folder located in a local VM.
How to enable “Azure App Service Local Cache”?
Enable the feature by having the WEBSITE_LOCAL_CACHE_OPTION = Always as shown below.
Disadvantages of Azure App Service Local Cache
- We must restart the App Service for each deployment to clear the local cache of each of the VMs.
- If you perform writes directly on the local store, you would lose all the changes whenever the VM is relocated or restarted.
- It’s created in the local VM on the startup of the App Service.
- The default memory allocated is 300 MB, but it is possible to extend it to 1 GB, but we need to set the following setting WEBSITE_LOCAL_CACHE_SIZEINMB to 1024.
- When the Virtual VM is re-located or the App Service is restarted, all the content in the Local Cache are cleared and its populated with the content available in the Shared Content, so take into account that all your previous job will be ERASED
- All deployments done by all different methods (FTP, Web Deploy etc.) will still be pointed to the Shared Content area. So, in order to get these changes reflected to the local cache, the App Service needs to be restarted in order to get the new changes reflected.
Till next time!
As you know, Azure App Services uses IIS or other mechanisms to run our Apps, the problem is when the Web App is not used in a determined period of time, the first petition to the web app will be slowly to load the first time, why? because the worker process that keeps the Web App running change the state to idle.
Once the Web App receive the first petition and has done this first load time, you can refresh with F5, and it will be ok again and the Web App will response inmediately.
If you’ve ever noticed this behavior an option might be to go inside of the Application Settings for the web app in the portal, and activating Always On, which keeps your web App Up and running constantly.
Keep in mind that you will not be able to turn this feature on when using the Free version of Azure App Services. It is only available in Basic or Standard plans.
We all know the power of Azure App Service, but as always we have a lot of data and a lof of services related with it.
Imagine that we have a Azure App Service and by human mistake we delete the production App Service, and what’s more, we don’t have Azure Backup configured for this Service, so probably all your company work will be lost.
To our luck, in Azure we have something what is called Azure App Service Web App Undelete where we can be able to restore the app without any support plan.
We have to take into account that this only works for sites deleted in the past 30 days, and we have to be sure that the Plan of our App Service is at least in Basic, this feature does not work in Free mode, but I still think that this is pretty cool, isn’t it?
So we will be able to restore the following:
- The content of the deleted app.
- The configuration of the app (the commands allows to skip the restoration of the app configuration).
- The undelete commands will also to restore the *.azurewebsites.net host name if still available.
So we can list the deleted apps and restore them, I am going to show you how to do it by PowerShell and CLI:
Restore-AzureRmDeletedWebApp -ResourceGroupName -Name -TargetAppServicePlanName
If we want to do it by using CLI, we need to execute the following:
az webapp deleted list --name <name of the deleted app>
az webapp deleted restore --deleted-id <id of the deleted app> --name <name of the app to restore to> --resource-group <resource group of the app to restore to>