Azure-docs: Enable Local Cache in staging slot

[dennis-yemelyanov]

We are thinking about enabling Local Cache to reduce the frequency of app restarts due to Azure storage upgrades.

We want staging and production slots to be identical (have Local Cache enabled for both slots) to avoid additional restarts during swap, but this page mentions that Local Cache is typically not enabled for a staging slot: "You typically don't set the staging slot to use Local Cache to enable a seamless build-deploy-test lifecycle for staging if you get the benefits of Local Cache for the production slot".

Why is it not recommended to enable Local Cache for a staging slot? If we are using the Azure DevOps App Service task to deploy, I think it restarts the staging slot site after deployment, so that should help to refresh the local cache with new binaries. Are there any other issues with having Local Cache enabled for both slots?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 93f1a8ab-c577-b9e8-b46e-28e0a90a0eae
• Version Independent ID: b716dcf9-1faf-fe60-b7be-f2bec92adbb5
• Content: Local cache - Azure App Service
• Content Source: articles/app-service/overview-local-cache.md
• Service: app-service
• GitHub Login: @cephalin
• Microsoft Alias: cephalin

[Grace-MacJones-MSFT]

Hi @dennis-yemelyanov, thank you for the detailed question. We are currently investigating and will update you when we have accurate information to provide.

[aadje]

We currently have the same question.
On our testing environments we haven't seen any issues related to having Local cache enabled for all slots.
We are also using Run-From-Package zip deployments in combination with local cache and slots.
The docs suggest that these features do not "compose". We can't reproduce any problems with enabling both options, while the docs basically suggest this can't work.
We like to reduce the App Restarts, have the fast atomic Run-From-Package deployments and have no deployment downtime using the the deployment slots.

[dennis-yemelyanov]

@Grace-MacJones-MSFT , any updates on this? Local Cache sounds like a really useful feature, but the lack of clarity about how to use it properly prevents multiple teams from using it

[BryanTrach-MSFT]

@aadje @dennis-yemelyanov Local cache is meant to provide a way to reduce downtime caused by storage failover events. These events shouldn't impact your staging slot since production traffic isn't using it. Following the below steps calls out the process by using slow swap preview to avoid restarts on your production slot and to avoid having to enable local cache on the staging slot, which we do not recommend.

 let's say you has local cache enabled 
    a. If you select regular slot swap
        i. Both w3wp.exe may recycle (here are the recycle conditions Slot swap restarts)
        ii. Production traffic will go to staging slot which will be running C3 using A2 settings
        iii. Staging traffic will go to production slot which will be running C1 using A1 settings
        iv. App init URL is invoked 
        v. Local Cache initialization starts
        vi. Once the local cache is ready
        vii. Another recycle occurs and this time App Init URLs aren't invoked 
    b. If you select Slot swap with preview
        i. Don’t click on the complete button until local cache is ready (Second restart)
8. Suggestion 
    a. Only one slot (production) should have Local Cache enabled. Other staging slot shouldn’t have local cache enabled.

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[blueelvis]

@BryanTrach-MSFT - We faced this issue where enabling the caching on both the production and the staging slots did not refresh the code on the production slot after a swap. The production slot had to be manually stopped and then started to refresh the cache. Tried this multiple times but still the issue was there. In the end, finally disabled the cache on both the production and the other slots because there isn't a proper way (There are clunky ways) to do this if you have App Settings also captured as part of your deployment configuration.

[BryanTrach-MSFT]

@blueelvis Yes, this is one of the risks and thus reasons why it's not recommended to enable local cache on both prod and staging slots. Thank you for sharing.