【问题标题】:Twisted script handling millions of connections处理数百万个连接的扭曲脚本
【发布时间】:2014-09-11 09:22:57
【问题描述】:

我编写了一个简单的网络服务,其中手持设备连接到服务器上的 Twisted 脚本。设备向脚本发送数据,脚本使用此数据查询 MySQL db,将 db 内容发送回设备。脚本基于本教程编写的脚本

http://www.raywenderlich.com/3932/networking-tutorial-for-ios-how-to-create-a-socket-based-iphone-app-and-server

这样的脚本如何处理大量连接?在我看来,它仅受服务器限制,服务器内存越高,您可以处理的连接量就越高。但是脚本在大量连接时会表现良好吗?对于每个连接,都会创建一个新的连接实例,并在有查询时为该连接创建一个新的数据库实例,所以我相信它都是异步处理的,服务器 CPU 功率和内存的唯一性能限制也是如此?通过扩展服务器来应对高连接量?对于我的服务,连接可能会在 1 到 3 小时之间保持打开状态,因此服务器内存可能会填满并导致服务器崩溃。

还有,有人知道连接实例的大小吗?

可能更多的是服务器问题而不是 Twisted 问题!但非常感谢您的阅读!

【问题讨论】:

  • 我想这更像是你所说的内核/tcp-ip-stack 问题——我怀疑 Twisted 对其自身施加了任何特定限制。阅读stackoverflow.com/q/2332741/66349,我建议您考虑重新设计您的架构。也许UDP会更合适?
  • 在没有明确理由的情况下切换到 UDP 是新手常见的错误。小心!

标签: python sockets asynchronous twisted


【解决方案1】:

您应该进行压力测试。您应该生成大量连接并查看性能如何下降。你可能没有问题,但如果你这样做了,你应该优化处理连接的代码,规范你的数据库和索引你的数据库字段。但是不需要过早的优化。

【讨论】:

  • 很好的答案。测试是唯一可以确定的通用方法。
  • 到目前为止,我觉得一旦有无限的 cpu 和内存,脚本就可以处理无限的连接。但我也认为这个脚本正在监听一个端口。这会导致大量连接出现很大的性能问题。有什么办法可以绕过这个瓶颈吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-10-21
  • 1970-01-01
相关资源
最近更新 更多