This results from a load test on our DNN portal, we tested to 20,000 concurrent users so hardly surprising we got slow results. A great MS support person gave us this general guidance which may help others.

____________________________________________________

Q- How do we load balance that situation for example? 

Ans- In Azure when you are running a web on multiple instances , the requests to application running on those instances are automatically load balanced . So you need not worry about load balancing the requests coming to your web apps.

Please do consider below recommendations for App Service availability and performance best practices:

It is advised to take following 7 actions as best practices for improving the app availability and performance. These steps will also help in ensuring the App resiliency during Azure Platform change (UD walk or File storage blip).

1. Ensure that the disk space used by www folder should be less than 1GB. It is a very healthy practice in reducing downtime during app restarts and hence improve the application performance. File system usage can be tracked from “App Service Plan à Quotas” section in Azure portal.
2. Use of local cache feature for the app. When this feature is enabled, the site content is read, written from the local virtual machine instance instead of fetching from Azure storage (where site content is stored). This will improve the performance of site during restarts and also will reduce the number of restarts required for the app. It can be enabled through Azure portal from the “General à Application settings”. On this page under the App settings section add WEBSITE_LOCAL_CACHE_OPTION as key and “Always” as value. Also add the WEBSITE_LOCAL_CACHE_SIZEINMB with a desired local cache size value up to 2000MB (if not provided, it defaults to 300 MB). It helps to provide the cache size specially when the site contents are more than 300 MB. Ensure that site contents are less than 2000MB for this feature to work. Also it is a good practice to keep it as a slot setting so that it does not get removed with a swap. The most important thing to keep in mind here is that app should not be doing local disk writes for state persistence of its data/transactions. External storage like storage containers, db or cosmos DB should be used for storage purposes. Read more at this blog

3. Ensure that multiple instances are allocated to the app. It is one of the commonly used healthy practices to have the app running on more than one instances. This ensures that the app is not down if something goes wrong with any particular instance. One thing to keep in mind here would be that the app code should be able to handle multiple instances without synchronization issues with common data read/write sources. Allocate multiple instances to your app using the “Scale out (App Service Plan)” section on Azure Portal. [We have a query on this as DNN is closing linked to its SQL?]

4. Enable Application Initialization to ensure that site (specific instance) is completely warmed before it is swapped into production and real customer traffic hits it. The warming up is also ensured in site restarts, auto scaling, and manual scaling. This is a critical feature where hitting the site’s base URL is not sufficient for warming up the application. For this purpose a health-check url must be created on the app which should be unauthenticated and App Init should be configured to use this url. Try to make sure that the method implemented by the health-check URL takes care of touching the functions of all important routes and it should return a response under 1 minute. If the health-check url returns a response under 1 minute (success or failure), app initialization will assume “everything is fine with the app”. App Initialization can be configured for your app within web.config file.

Read more here for details on using the feature.

5. Enable Health Check feature  (https://nam06.safelinks.p...eHFw%3D&reserved=0). It is used to exclude the unhealthy instance(s) from serving requests and improve reliability. You can specify the endpoint of your application that represents the health of your web app. It is advised to use the same health-check url which is created in step 4. Our service will ping the health check path on all instances every 2 mins. If an instance does not respond within 10 minutes (5 pings), the instance is determined to be "unhealthy" and our service will stop routing requests to it. To setup health check feature go to “Development Tools à Resource Explorer” on the web app blade for Azure portal

 Image missing

On the resource explorer page, expand the "config" section and click the "web" tab. Add an element with the name, "healthCheckPath", and whose value is the path of your health-check url that our service will ping.

Image missing

6. Enable auto heal on the app. I would recommend to create an auto heal mitigation rule by going to “Diagnose and Solve problems” section, selecting the “Diagnostic Tools” tile and then “Auto Healing” under Proactive Tools section.

Image Missing

Below are recommended filter values to set up (if some other value of error code and frequency suits your application, please modify accordingly)

Define Conditions (Status Codes)

Request Count: 70

Status Code: 500

Sub-status code: 0

Win32-status code: 0

Frequency in seconds: 60

              Configure Action

                             Recycle Process

              Override when Action Executes

                             Startup Time for process before auto heal executes: 3600 seconds (1 hour)

7. Ensure not more apps are running on the app service plan to ensure healthy performance. All the apps running on the app service plan can be seen on “Apps” under “Settings” section in your app service plan on azure portal.