python并发性能_python几种并发实现方案性能比较

python几种并发实现方案性能比较

前言 1. 偶然看到Erlang vs. Stackless python: a first benchmark， 对Erlang和 Stackless Python的并发处理性能进行了实验比较，基本结论认为二者有比较 相近的性能。我看完产生的问题是，Stackless Python与Python的其他并发 实现机制性能又会有多大区别呢，比如线程和进程。因此我采用与这篇文章相 同的办法来对Stackless Python、普通Python的thread模块、普通Python 的threading模块、普通Python的processing模块这四种并发 实现方案进行 了性能实验，并将实验过程和基本结果记录在这里。 后来看到了基于greenlet实现的高性能网络框架Eventlet，因而更新了实验 方案，将greenlet也加入了比较，虽然greenlet并非是一种真正意义上的并 发处理，而是在单个线程下对程序块进行切换轮流执行。 (Edit Section ↓)实验方案 2. 实验方案与Erlang vs. Stackless python: a first benchmark是相同的，用 每种方案分别给出如下问题的实现，记录完成整个处理过程的总时间来作为评 判性能的依据： 1. 由 n个节点组成一个环状网络，在上面传送共 m 个消息。 2. 将每个消息(共 m 个) ，逐个发送给 1号节点。 3. 第 1到 n-1 号节点在接收到消息后，都转发给下一号节点。 4. 第 n号节点每次收到消息后，不再继续转发。 5. 当 m 个消息都从 1号逐个到达第 n号节点时，认为全部处理结束。 (Edit Section ↓)硬件平台 2.1 Macbook Pro 3,1上的Vmware Fusion 1.0虚拟机中，注意这里给虚拟机只启 用了cpu的单个核心：  原始 Cpu：Core 2 Duo，2.4 GHz，2 核心，4 MB L2 缓存，总线速度 800 MHz  分配给虚拟机的内存：796M (单个CPU，还能比较并发吗？) (Edit Section ↓)软件平台 2.2Vmware Fusion 1.0下的Debian etch：  原始 Python：Debian 发行版自带 Python 2.4.4  Python 2.4.4 Stackless 3.1b3 060516  processing-0.52-py2.4-linux-i686.egg  原始 Python 下的 greenlet 实现：py lib 0.9.2 (Edit Section ↓)实验过程及结果 3. 各方案的实现代码见后文。实验时使用time指令记录每次运行的总时间，选用 的都是不做任何输出的no_io实现(Python的print指令还是挺耗资源的，如 果不注释掉十有八九得影响测试结果)，每次执行时设定 n=300，m=10000(Erlang vs. Stackless python: a first benchmark文章中 认为n可以设置为300，m则可以取10000到90000之间的数值分别进行测试)。(Edit Section ↓)Stackless Python的实验结果 3.1 real 0m1.651s user 0m1.628s sys 0m0.020s 即使将m扩大到30000，实验结果仍然很突出： real 0m4.749s user 0m4.716s sys 0m0.028s (Edit Section ↓)使用thread模块的实验结果 3.2 real 1m13.009s user 0m2.476s sys 0m59.028s (Edit Section ↓)使用threading模块配合Queue模块的实验结果 3.3 不太稳定，有时候这样： real 1m9.222suser 0m34.418s sys 0m34.622s 也有时这样： real 2m14.016s user 0m6.644s sys 2m7.260s (Edit Section ↓)使用processing模块配合Queue模块的实验结果 3.4 real 3m43.539s user 0m15.345s sys 3m27.953s (Edit Section ↓)greenlet模块的实验结果 3.5 real 0m9.225s user 0m0.644s sys 0m8.581s (Edit Section ↓)eventlet模块的实验结果 3.6 注意！eventlet 的这个实验结果是后来增补的，硬件平台没变，但是是直接在 OSX 自带 Python 2.5 环境下执行出来的，同时系统中还有 Firefox 等很多程 序也在争夺系统资源。因此只能作为大致参考，不能与其他几组数据作直接对 比。(其中 eventlet 的版本是 0.9.5) real 0m21.610s user 0m20.713s sys 0m0.215s (Edit Section ↓)结论与分析 4. (Edit Section ↓)Stackless Python 4.1 毫无疑问，Stackless Python几乎有匪夷所思的并发性能，比其他方案快上几 十倍，而且借助Stackless Python提供的channel机制，实现也相当简单。也许这个结果向我们部分揭示了沈仙人基于Stackless Python实现的Eurasia3 能够提供相当于c语言效果的恐怖并发性能的原因。 (Edit Section ↓)Python线程 4.2 从道理上来讲，thread模块似乎应该和threading提供基本相同的性能，毕竟 threading只是对thread的一种封装嘛，后台机 制应该是一致的。或许 threading由于本身类实例维护方面的开销，应该会比直接用thread慢一点。 从实验结果来看，二者性能也确实差不多。只是 不大明白为何threading方案 的测试结果不是很稳定，即使对其他方案的测试运行多次，误差也不会像 threading这么飘。从代码实现体验来说， 用threading配合Queue比直接用 thread实在是轻松太多了，并且出错的机会也要少很多。 (Edit Section ↓)Python进程 4.3 processing模块给出的进程方案大致比thread线程要慢一倍，并且这是在我 特意调整虚拟机给它预备了足够空闲内存、避免使用交换分区的 情况下取得的 (特意分给虚拟机700多M内存就是为了这个)。而其他方案仅仅占用数M内 存，完全无需特意调大可用内存总量。当然，如果给虚拟机多启用几个 核心的 话，processing也许会占上点便宜，毕竟目前thread模块是不能有效利用多 cpu资源的(经实验，Stackless Python在开启双核的情况下表现的性能和单 核是一样的，说明也是不能有效利用多cpu)。因此一种比较合理的做法是根 据cpu的数量，启用少量几个进 程，而在进程内部再开启线程进行实际业务处 理