Azure App Service TCP/IP Port Exhaustion

4
votes

I recently got a "recommendation" from Azure regarding reaching the upper limit for TCP/IP ports in my App Service.

TCP/IP ports near exhaustion Your app service plan containing app ****** is configured to use medium instances. The apps hosted in that App Service plan are using more than 90% of the 4096 available TCP/IP ports available per medium instance. You can upgrade the instance size to increase the outbound connection limit or configure connection pooling for more efficient use.

Is there a difference in Limits for App Service Plans (scale up)? or can I Configure my App Service to use more ports? Or is there any other solution for this?

An obvious solution would be scaling out, but since CPU and Memory usage is low I would rather not use this option if not necessarily.

As background, the service is an API built with ASP.NET Core MVC using .Net 4.6.

2
azureazure-app-service-plans
What are you calling that you have so many outbound ESTABLISHED connections? Are you sure you're not leaking connections in there somewhere? – evilSnobu
You are right, I should not be having that many open connections. I have around 100 calls per second (its an API) so I am not sure why it's so many. I start a lot of connections to other services (Cassandra, MSSQL, RabbitMQ etc) but I am not sure of those connection counts as well. And I think the libraries used should be pretty efficient since I am careful to use singletons when possible. – Fischer

2 Answers

2
votes

Yes, there is a difference in Limits for App Service Plans (scale up):

The maximum connection limits are the following:

1,920 connections per B1/S1/P1 instance 3,968 connections per B2/S2/P2 instance 8,064 connections per B3/S3/P3 instance

Regarding: other services (Cassandra, MSSQL, RabbitMQ etc) but I am not sure of those connection counts as well This services calls will also result in TCP connection creation and need to be counted as well.

Most of the services in Azure are having their own Diagnostics and Dashaboard which we can correlate while doing debugging, like in my case MSSQL DTU was not sufficient to hold the number of concurrent requests and because of that the connections are piling up.

Source:

https://blogs.technet.microsoft.com/latam/2015/06/01/how-to-deal-with-the-limits-of-azure-sql-database-maximum-logins/

https://blogs.msdn.microsoft.com/appserviceteam/2018/03/01/deep-dive-into-tcp-connections-in-app-service-diagnostics/

0
votes

Usually we instantiate and dispose after making a call within .NET but there is a gotcha for HttpClient class as we should be reusing the same class throughout the lifecycle of the application.

Azure ports are limited within its computing environment so you would experience that sooner compared to a standard server.

Read through this below: Reusing HttpClient