Always On

Azure unloads your site if it is idle for the standard 20 minute timeout, which can cause slow
responses for the initial site users after it is unloaded. Enabling Always On essentially causes
Azure to automatically ping your site periodically to ensure that it remains in a running state.
There is no charge for enabling Always On, but is not an available option on lower end plans. I
suppose in theory it could consume more CPU cycles and thus could require the deployment of
more infrastructure if you have many, many sites.

As an aside, "Always On" for Azure websites should not be confused with AlwaysOn Failover
Clustering/Availability Groups for SQL Server.

Azure unloads your site if it is idle for the standard 20 minute timeout, which can cause slow
responses for the initial site users after it is unloaded. Enabling Always On essentially causes
Azure to automatically ping your site periodically to ensure that it remains in a running state.
There is no charge for enabling Always On, but is not an available option on lower end plans. I
suppose in theory it could consume more CPU cycles and thus could require the deployment of
more infrastructure if you have many, many sites.

As an aside, "Always On" for Azure websites should not be confused with AlwaysOn Failover
Clustering/Availability Groups for SQL Server.

n Windows Azure, when the feature is enabled, the root url of your site will be hit every few
seconds. The initiating request will keep your site alive and ready to accept other requests.

Knowing that you should follow these rules when enabling the Always On feature:

 Make sure you have a root url / handler

 Make sure you don't log 404 errors for hitting the root if you don't have one
 Make sure your root is not an expensive operation

When moving to the cloud, we carry along our old assumptions with us. Hopefully this helps
clear up how Always On works in Windows Azure.

Application Request Routing

ARR Affinity is enabled on your Azure App Service by default. This means that if you are running
multiple instance of your App Service, clients will be directed to the same instance for each
request. Here is an article that contains more information on the subject. However, now it is possible
to perform the enable or disable of this feature from within the Azure portal instead of making a
manual configuration change to the web.config file.

I have seen some reports from customers where they are performing some performance testing and
see slow or limited improvement after increasing the number of ASP instances. In many cases it is
because the client remains on the same single instance due to the default ARR Affinity setting. If
your App Service is state-less then you can disable ARR Affinity and would then get different results.

At the same time, the App Service front ends do balance using * algorithm, but as soon as a client is
affinitized, it remains in that state until the session ends, new clients would/could be redirected to
the other instances.

https://dzimchuk.net/application-request-routing-in-azure-web-apps/