Using Azure File Share for NuCache files for load balanced multi-subscriber environments
Greetings,
we are using Umbraco following Load Balanced Environments guidelines. We are using Container Apps to benefit advanced scaling capabilities. We adjusted a readiness probe to scale out successfully but while checking logs, it takes quite much time to read everything from database to warm up new Subscriber instance. This sometimes ends up with failure.
To achieve quicker bootup, we are considering persisting umbraco/Data folder using Azure File Share to populate content/media cache from NuCache files.
Do you see any implications sharing this folder by N amount of instances? Would it be safe? Because it takes only 5 seconds spinning up a new Subscriber instance when content/media cache read from file. Meanwhile, it takes over 40 seconds (maybe even more depending on the load on SQL) when cache is populated from database. So we are very eager to give it a try but I am not sure about NuCache intrinsic.
Using Azure File Share for NuCache files for load balanced multi-subscriber environments
Greetings,
we are using Umbraco following Load Balanced Environments guidelines. We are using Container Apps to benefit advanced scaling capabilities. We adjusted a readiness probe to scale out successfully but while checking logs, it takes quite much time to read everything from database to warm up new Subscriber instance. This sometimes ends up with failure.
To achieve quicker bootup, we are considering persisting umbraco/Data folder using Azure File Share to populate content/media cache from NuCache files.
Do you see any implications sharing this folder by N amount of instances? Would it be safe? Because it takes only 5 seconds spinning up a new Subscriber instance when content/media cache read from file. Meanwhile, it takes over 40 seconds (maybe even more depending on the load on SQL) when cache is populated from database. So we are very eager to give it a try but I am not sure about NuCache intrinsic.
Kind regards, Kerem
is working on a reply...