Most run less than 10 apps per service plan. Ensure you prevent over saturating resources:
- If you require a lot of compute or run on multiple servers due to high CPU util or memory pressure consider traffic distribution and seperate long tail or low volume apps. Ex:
- 40 low volume apps on one plan running one compute
- Five mid-to-low use a second App Service Plan
- The remaining on a high-volume usage
Net result of the aforementioned is approximately 50 apps using 7 compute resources at miniumum, giving the 5 high volume apps headroom with regards to memory and CPU.
Alternative for running large numbers of apps more efficiently App service high density hosting
Deployment Slots by default each an application slot is created in the App Service Plan, all appplications in the service plan are running on the same set of underlying servers as production. Stress tests will impact, if resource comptetion or load testing here are some recommendations
- Create additional App Service Plan for the non-production slots. Important note: Each App Service Plan needs to be in the same resource group and same region as the production slot’s App Service Plan.
- Move a non-production slot to a different App Service Plan and, thus, a separate pool of compute resources.
- Carry out resource-intensive (or risky) tasks while running in the separate App Service Plan. For example, load tests can be run against a non-production slot without negatively impacting the production slot because there won’t be any resource contention.
- When the non-production slot is ready to be swapped into production, move it back to the same App Service Plan running the production slot. Then the slot swap operation can be carried out.
Deploy to Production with No Downtime
Awesome app, great people and process supporting and controlling deployment and minimize downtime, applicatoin needs to warm up before prod load
- Use your deployment slots set deployments to pre-production slot, warm up if needed, then perform the Virtual IP Switch. VSTS Release tools can setup a pipeline to accomodate
Scale Unit Network Config
Scale units get a single Virtual IP (VIP), App Service apps only serve on 80 and 443 each service has built in HTTPS support. App Service support Server Name Indicator (SNI) and IP - based SSL. In the case of IP SSL app is allocated dedicated IP for inbound. Front ends terminate all HTTPS requests for all apps, the front end then forwards request to designated worker.
Default single public VIP.
PS C:\> nslookup smrtrock.blog
Likely app is connected to other Azure and non-Azure services, outbound calls to enpoints not on the same scale unit. There are up to 5 VIPs 1 public and four outbound dedicated VIPs for outbound.
- If the service or API requires whitelisting IPs allowed to make API calls then all VIPs must be accounted for here is where you can find them
If you’re looking for a dedicated set of inbound and outbound IPs, you can explore this by using a fully isolated and dedicated App Service Environment at Intro to App Service v1.
IP and SNI SSL
App Service supports IP-based SSL certificates. When using IP-SSL, App Service allocates to your application a dedicated IP address for only in-bound HTTP traffic.
Unlike the rest of Azure dedicated IP addresses, the IP address with App Service via IP-SSL is allocated as long as you opt to use it. You don’t own the IP address and when you delete your IP-SSL, you might lose the IP address (as it might be allocated to a different application).
App Service also supports SNI SSL, which doesn’t require a dedicated IP address and is supported by modern browsers.
Network Port Capacity for Outbound Network Calls
Common requirement ability to make outbound calls to other endpoints including to other Azure services. In almost all cases the calling app is implicitly opening a socket. Calls made from Azure App Service to remote Azure Services Azure Networking setups and manages Network Address Translation (NAT). Creating new entries takes time
Max connection limits
- 1,920 per B1/S1/P1 instance
- 3,968 per B2/S2/P2 instance
- 8,064 per B3/S3/P3 instance
- 64 max upper limit per App Service
Apps that leak connections invariably run into connection limits. Here are some mitigation strategies
- For .NET applications using ADO.NET/EF, use database connection pooling.
- For php/mySql, use persistent database connections.
- For Node.js applications making outbound HTTP/HTTPS calls, configure keep-alives so that outbound connections are reused. This configuration is described at Scenarios and recommendations/troubleshooting.
- For .NET applications making outbound HTTP/HTTPS calls, pool and reuse instances of System.Net.Http.HttpClient or use Keep-alive connections with System.Net.HttpWebRequest. Note: Remember to increase the System.Net.ServicePointManager.DefaultConnectionLimit because you’ll otherwise be limited to two concurrent outbound connections to the same endpoint.
There are additional limitations imposed by the App Service Sandbox. These are lower-level limits and constraints for Azure App Service and you can read about them in more detail at Project Kudu.
Reference MSDN - February 2017