网络服务速度减慢

发布于 2024-07-13 09:15:22 字数 558 浏览 7 评论 0 原文

我的网络服务速度变慢。 我的(网络)服务位于 gsoap & 托管C++。 它不是 IIS/apache 托管的,但使用 xml。 我的客户端在 .NET 中 服务计算时间很短(<0.1秒准备回复)。 我希望服务能够顺利、快速并且具有良好的可用性。 我有大约 100 个客户端,响应时间强制为 1 秒。 客户端每分钟大约有 1 个请求。 客户端通过 TCP 开放端口测试来检查 Web 服务是否存在。 因此,为了避免可能出现的拥塞,我将 gSoap KeepAlive 设置为 false。 直到一切都运行良好:我几乎在 TCPView (sysinternals) 中看到连接

新的特殊同步程序现在循环调用该服务。 它的负载较高,但所有内容都可以在 30 秒内处理完毕。 通过 sysinternals TCPView,我看到大约 1000 个连接处于 TIME_WAIT 状态。 他们减慢了服务速度,现在服务需要几秒钟才能回复。

我是否需要重置 SoapHttpClientProtocol 连接? 有人在循环调用 Web 服务时出现 TIME_WAIT 幽灵吗?

I have a web service slowdown.
My (web) service is in gsoap & managed C++. It's not IIS/apache hosted, but speaks xml.
My client is in .NET
The service computation time is light (<0.1s to prepare reply). I expect the service to be smooth, fast and have good availability.
I have about 100 clients, response time is 1s mandatory.
Clients have about 1 request per minute.
Clients are checking web service presence by tcp open port test.
So, to avoid possible congestion, I turned gSoap KeepAlive to false.
Until there everything runs fine : I bearly see connections in TCPView (sysinternals)

New special synchronisation program now calls the service in a loop.
It's higher load but everything is processed in less 30 seconds.
With sysinternals TCPView, I see that about 1 thousands connections are in TIME_WAIT.
They slowdown the service and It takes seconds for the service to reply, now.

Could it be that I need to reset the SoapHttpClientProtocol connection ?
Someone has TIME_WAIT ghosts with a web service call in a loop ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

时光暖心i 2024-07-20 09:15:22

听起来您没有在通话后关闭连接并在每个请求上打开新连接。 关闭连接或重新使用打开的连接。

Sounds like you aren't closing the connection after the call and opening new connections on each request. Either close the connection or reuse the open connections.

ゝ杯具 2024-07-20 09:15:22

对于上面提到的实现要非常小心。 他们有严重的问题。

  1. yakkowarner.blogspot.com/2008/11/calling-web-service-in-loop.html(上面的评论)中描述的实现:

    问题:下次使用 wsdl.exe 重新生成 Web 服务时,您的所有工作都将被清除,并且您会忘记您所做的事情,更不用说此修复程序相当 hacky了依靠消息字符串来采取行动。

  2. forums.asp.net/t/1003135.aspx 中描述的实现(上面的评论):

    问题:您选择的端点介于 5000 和 65535 之间,因此从表面上看,这似乎是个好主意。 如果您考虑一下,就没有办法(至少我想不到)您可以保留端口以供以后使用。 如何保证列表中的下一个端口当前未被使用? 您将按顺序选择要使用的端口,如果其他应用程序选择了列表中的下一个端口,那么您就会被淹没。 或者,如果您的客户端计算机上运行的某些其他应用程序开始使用随机端口进行连接,该怎么办 - 您将在不可预测的时间点受到攻击。 您会随机收到一条错误消息,例如“无法访问远程主机或不可用” - 更难排除故障。

虽然我无法为您提供解决此问题的正确解决方案,但您可以做的一些事情是:

  1. 尝试最大程度地减少 Web 服务请求的数量或将它们分散在更长的时间内
  2. 对于您的应用程序类型,Web 服务可能不是这不是正确的体系结构 - 对于响应时间为 1ms 的系统,您应该使用消息传递系统 - 而不是 Web 服务
  3. 使用注册表将操作系统允许的连接数设置为 65K,就像在 Windows 中一样
  4. 将操作系统的套接字保持在 TIME_WAIT 状态的时间设置为某个时间较低的数字(这提出了自己的问题列表)

Be very careful with the implementations mentioned above. There are serious problems with them.

  1. The implementation described in yakkowarner.blogspot.com/2008/11/calling-web-service-in-loop.html (COMMENT ABOVE):

    PROBLEM: All your work will be be wiped out the next time you regenerate the web service using wsdl.exe and you are going to forget what you did not to mention that this fix is rather hacky relying on a message string to take action.

  2. The implementation described in forums.asp.net/t/1003135.aspx (COMMENT ABOVE):

    PROBLEM: You are selecting an endpoint between 5000 and 65535 so on the surface this looks like a good idea. If you think about it there is no way (at least none I can think of) that you could reserve ports to be used later. How can you guarantee that the next port on your list is not currently used? You are sequentially picking up ports to use and if some other application picks a port that is next on your list then you are hosed. Or what if some other application running on your client machine starts using random ports for its connections - you would be hosed at UNPREDICTABLE points in time. You would RANDOMLY get an error message like "remote host can't be reached or is unavailable" - even harder to troubleshoot.

Although I can't give you the right solution to this problem, some things you can do are:

  1. Try to minimize the number of web service requests or spread them out more over a longer period of time
  2. For your type of app maybe web services wasn't the correct architecture - for something with 1ms response time you should be using a messaging system - not a web service
  3. Set your OS's number of connections allowed to 65K using the registry as in Windows
  4. Set you OS's time that sockets remain in TIME_WAIT to some lower number (this presents its own list of problems)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文