【发布时间】：2015-12-03 18:34:31
【问题描述】：
我在部署到 Azure 应用服务的 Web 应用程序上遇到 TCP/IP 端口耗尽错误。该问题与占用端口的 RavenDB 连接会话有关。我认为我有一个修复程序并且应该很好，但我觉得自己被淘汰了，因为我真的无法在部署的环境中进行调试。
在调试问题时，我尝试访问 netstat，但我收到访问被拒绝消息，似乎无法绕过它。有什么想法吗？
切线：如何在 Azure Web 应用程序中分配端口？提出的选项（如https://msdn.microsoft.com/en-us/library/aa560610(v=bts.20).aspx 中所述）用于减少套接字连接超时值或增加动态分配给客户端 TCP/IP 套接字连接的端口上限。但是，我认为这在 Azure Web Apps 中是不可能的。
【问题讨论】：
-
嗨@JoanieBrar，我们遇到了类似的问题。我现在开始调查，并会带着可能的发现回到这篇文章——但在我开始之前，你能告诉我你修复的是什么吗？白盒减少 Raven 调用，扩展端口范围，还是？
-
老实说，我们的 Web 应用程序在这方面仍然遇到一些挑战。我们能够通过拔出 Signal R 来消除当前流量负载的问题（从本质上讲，它会更长时间地保持会话），谨慎地确定会话何时打开，并在不再需要时关闭会话时遵守纪律.然而，在我们的积压工作中仍然是一个需要重新审视的问题，因为随着负载的增加，我们预计端口耗尽会重新出现。抱歉，我无法提供更多帮助或提供任何更深入的见解。
-
我们在调试 Azure 中的端口耗尽时遇到了类似的问题。我们在一个定价计划中有 20 多个应用程序，目前“计划”似乎也是一个虚拟机，并且该计划中的所有应用程序同时失去 tcp 连接。目前无法通过门户或 powershell 识别哪个应用程序是罪魁祸首，到目前为止，MSFT 技术支持也无法判断哪个应用程序是罪魁祸首，
-
我知道这是一个旧线程，但我们现在遇到了同样的问题。我们也使用 Signalr，但 websockets 在 azure 上应该是无限制的。 signalR 是否也以某种方式消耗常规连接？我们只是使用 build in web api 和 entityframework，所以根本不像我们控制连接，但是它们会堆积起来，有时会随着时间的推移逐渐增加，有时会相对突然，直到我们达到极限并且整个 VM 崩溃。
标签： azure tcp ravendb azure-web-app-service