2

我正在通过 WAN 处理来自多个 XMLRPC 客户端的请求。这个东西非常适合，比如说，一天（有时是两天），然后在 socket.py 中冻结：

data = self._sock.recv(self._rbufsize)

_sock.timeout 为 -1，_sock.gettimeout 为无

我在主线程中没有什么特别的（只是接收 XMLRPC 调用），还有另外两个线程与 DB 通信。这两个线程都工作正常并且在这个块中存活下来（用 WinPdb 进行了检查）。客户端发送的请求不超过 1KB，并且没有任何特殊内容：只是字典中漂亮而干净的字符串。在两次阻塞之间，我可以毫无问题地处理数万个请求。防火墙已关闭，同一台机器上没有奇怪的软件等...

我使用 Windows XP 和 Python 2.6.4。我检查了 2.6.4 之间的差异。和 2.6.5，并没有发现任何重要的东西（或者我弄错了吗？）。2.7 版本不是一个选项，因为我会错过 MySqlDB 的二进制文件。

由互联网连接不良的客户端不时发生的唯一事情是套接字中断。这种情况每 5-10 分钟发生一次（每 2 秒只有五个客户端访问服务器）。

我在这个问题上花了很多时间，现在我开始失去任何想法该做什么。任何提示或想法将不胜感激。

4

2 回答 2

1

您的操作系统的 TCP/IP 堆栈中究竟发生了什么（可能在顶部的 python 层中，但不太可能）导致这是一个谜。作为一种实用的解决方法，我将超时设置为比您期望的请求之间的延迟更长（如果您希望每 2 秒请求一次，则 10 秒应该足够了），如果发生，请关闭并重新打开。（通过反复试验校准在不中断正常流量的情况下解决冻结所需的延迟）。我知道，在不了解问题的情况下破解修复程序是不愉快的，但是在编写、部署和操作实际服务器系统的世界中，对这些事情务实是必要的生存特征。请务必为未来的维护人员准确地评论解决方法！

于 2010-07-17T16:00:05.270 回答
0

非常感谢您的快速响应。在我收到它之后，我将超时时间增加到 10 秒。现在一切运行都没有问题，但当然我需要再等一两天才能得到某种确认，但只有在 5 天后我才能确定并且会带着结果回来。我现在看到 140K 的请求已经很顺利了，在这方面有如此艰苦的经验，我至少会再等 200K。

您提出的关于自动适应超时（不关闭系统）的建议听起来也很合理。正确的方法是创建一个小类（例如 AutoTimeoutCalibrator）并将其直接嵌入到 serial.py 中吗？

是的 - 务实是唯一的方法，而不会失去另外 10 天的时间试图找出背后的真正原因。

再次感谢，我会带着结果回来的。（对不起，但由于某种原因，我无法将其发布为对您帖子的回复）

于 2010-07-18T10:18:53.380 回答