Azure应用服务TCP/IP端口耗尽
最近，我从Azure获得了一条关于在我的应用程序服务中达到TCP/IP端口上限的“建议”。
TCP/IP端口接近耗尽包含应用程序*****的应用程序服务计划已配置为使用中等实例。该应用服务计划中托管的应用程序使用了每个中型实例4096个可用TCP/IP端口中的90%以上。您可以升级实例大小以增加出站连接限制，或配置连接池以更高效地使用。
应用程序服务计划的限制是否存在差异（扩大）？或者我可以配置我的应用程序服务以使用更多端口吗？还是有其他解决方案？
一个明显的解决方案是向外扩展，但由于CPU和内存使用率较低，如果不一定，我宁愿不使用此选项。
作为后台，该服务是使用ASP构建的API。NET核心MVC使用。净额4.6。
共有2个答案
通常我们在内部调用后实例化和处置。NET但是HttpClient类有一个问题，因为我们应该在应用程序的整个生命周期中重用同一个类。
Azure端口在其计算环境中受到限制，因此与标准服务器相比，您可以更快地体验到这一点。
阅读以下内容：重用HttpClient
是的，应用程序服务计划的限制存在差异（放大）：
最大连接限制如下：
每个B1/S1/P1实例1,920个连接每个B2/S2/P2实例3,968个连接每个B3/S3/P3实例8,064个连接
关于：其他服务（Cassandra、MSSQL、RabbitMQ等），但我不确定这些连接的数量。这些服务调用还将导致TCP连接的创建，并且也需要计算。
Azure中的大多数服务都有自己的诊断和Dashboard，我们可以在进行html" target="_blank">调试时将其关联起来，比如在我的情况下，MSSQL DTU不足以容纳并发请求的数量，因此连接正在堆积。
来源：
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/
-
tcp 服务端 tcp 服务端 源码/* * Copyright (c) 2006-2018, RT-Thread Development Team * * SPDX-License-Identifier: Apache-2.0 * * Change Logs: * Date Author Notes * *//** 程序清单：tcp 服务端 * * 这是一个 tcp 服务端的例程 * 导出 tc
-
我有一个Android Studio应用程序，用于客户端读取加速计的数据，并将其发送到运行TCP C套接字服务器的计算机。 我想等到服务器确认接收到数据后再发送一个。当我不得不从Android系统读取服务器的确认信息时，问题就出现了，这只是简单的崩溃，我不知道为什么。这是我使用的代码。 服务器代码 和客户端代码（Android Studio） 我在交流中遗漏了什么还是我做错了什么？
-
我正在使用TCP / IP流编写客户端服务器Java程序，我的服务器连接到oracle数据库。当客户端请求一些信息时，服务器处理查询，即返回一个包含一些行的列（例如 5）。我想将整列发送回客户端，我能够发送和接收单行数据，但不能发送和接收多行（因为表包含许多行 i，e 行）....任何帮助都是可取的
-
我们有几个服务总线侦听器在应用服务中作为连续的Azure Web作业运行。总而言之，有12个侦听器-网络作业在同一个S1应用服务计划上运行。环境很小，每天总共大约有1000-10000条消息。最近我们部署了一个新的监听器（一个监听器，它会定期将DLQ消息重新发送到原始主题长达24小时 我分析了代码，但没有发现高传输控制协议需求的原因。 所有侦听器都像这样工作（. NET控制台应用程序，在应用服务中
-
我想在Linux上的Azure应用服务（容器的网络应用）上使用scrapinghub/spash容器。 但是部署上的docker run命令会随机更改容器端的绑定端口（请参阅下面的日志，端口8961会自动分配。此数字每次部署都有所不同） 2020-01-21 08:56:47.494信息-docker run-d-p 8961:8050-名称b2scraper-splash\u 3\u d89ce
-
最近，在WebJobs中，我们一直在监视和识别导致app Service plan实例TCP端口耗尽的app时遇到问题。当一个应用程序导致端口耗尽时，同一计划中的所有应用程序都将关闭，目前无法通过Azure Portal或后端监控来诊断罪魁祸首。 我想知道消费计划中的Azure功能在这方面有何不同，包括监控、伸缩机制和对同一计划中其他功能的影响，以及诊断此类事件的原因。