扩展asyncore.dispatcher的HTTP类

Question

有没有使用asyncore.dispatcher的“标准”或众所周知的类？

我可以做一个，但我不想再发明轮子了:)

Answer 1

简短的回答是:不，至少不是你想要使用的任何东西。

大多数人认为，作为如何编写select-based事件循环的“示例代码”，asyncore在某种程度上是有用的，但作为实际项目的框架，除了简单的复杂性之外，它没有什么用处。

过去有一些项目是在asyncore之上构建一些严肃的东西，包括至少一个web服务器，但我不知道web客户端。这并不意味着没有这样的东西存在，…但我不希望它得到很好的维护或大量使用。

人们没有在asyncore之上构建更高级别的框架，而是更多地关注从头开始构建新的框架。最流行的可能是twisted (它的体系结构与asyncore有点相似，但更强大、更灵活)和gevent (它非常不同-它允许您以同步/多线程的方式编写代码，并且它神奇地通过事件循环周围的单个线程中的greenlet运行)。

同时，Guido和朋友们正在设计一个新的、现代的异步库(详情请参阅PEP 3146和tulip )，它可能会出现在3.4版本中，可能会弃用asyncore。

因此，您的选择是：

• 为旧的、部分完成的实现自行构建它，并完成它。
• 使用twisted、gevent、tulip等。

H122使用不同的高级抽象，如C23(或包装D24及其API的任何其他库)或C26(使用gevent).异步非常高级的客户端库

当然，是否真的需要单线程事件循环也是值得考虑的。大多数客户端应用程序不需要处理十几个左右的连接，并且每个套接字的线程可以在任何平台上轻松处理这些连接。(当然，如果您有任何CPU限制的代码，Python线程会很糟糕，但是基于单线程事件循环的代码就更糟糕了，所以我假设这不是问题。)

首先，对你的评论有几点一般性的评论：

我不确定你所说的“性能”是什么意思。通常，使用网络应用程序，您会担心可伸缩性:您可以处理多少并发连接，每秒可以创建多少新连接，您可以维持多少吞吐量，等等。性能-通常是根据您在稳定状态的工作流中使用的CPU/功耗/散热来衡量的-通常只有在您获得了所需的所有可扩展性之后才会发挥作用，即使到那时，您也只有在计划运行数十个堆满服务器的房间时才会考虑性能。

无论如何，我不知道你在测试什么，但所有这些选项都明显超过了Linux和Mac /*BSD上的asyncore，并且在任何人都做过的合理测试下，在Windows上完全超过了它。他们将使用IOCP、epoll或kqueue，而不仅仅是poll。他们中的一些人还将中心代码放在C中，他们都在大量的实际使用中进行了广泛的测试和调整，而自从十多年前添加了对asyncore的支持以来，poll没有任何改进。(这并不是因为asyncore已经足够好了，而是因为它还不够好，不值得改进。)

但对于客户端应用程序，可伸缩性和性能通常都不是问题。仅仅从几十个站点进行并行下载通常就足以饱和你的FTTH/cable/DSL/等带宽，除此之外，你还想要什么？

因此，我建议这些替代方案的原因不是为了性能或可伸缩性，而是为了简单性和完整性。Twisted的超文本传输协议客户端或grequests意味着你只需要写5行代码，你就有了可以工作的东西，所有困难的部分都已经经过了深思熟虑和严格的测试。即使是自己构建它，在gevents上运行httplib/urllib2/whatever所需的工作量也要少得多(并且提供的机会也少得多)，而不是拆分它并围绕asyncore重新构建它，而不是阻塞套接字。

扭曲了-我是初学者，没有那么多的时间去投资，至少现在是这样。

虽然twisted显然是一个巨大的项目，但您不必学习所有的内容，对于初学者来说，使用它应该比使用asyncore容易得多。请看我前面给出的链接中的HTTP客户端示例。这与使用httplib和asyncore做同样的事情需要多少代码进行比较。

gevent -性能类似于asyncore，但服务器负载太高。

如果服务器负载太高，那只能说明你的客户端运行得太快了，…这是一个很好的问题；您总是可以限制过快的客户端，但对于过慢的客户端，您通常不能做太多事情，只能重写整个过程。