头脑发热地搞山寨：StacklessIO 动手篇

接续着头脑发热地搞山寨：StacklessIO YY篇，YY后，就开始动手：

首先是命名，由于是寨品，所以也来个寨明： StacklessIOFQ

为毛是FQ，请留意在下头像。

按照YY篇分析出来的模型动手，直接挪用之前玩过的stackless socket，

建立进程、socket管理都很顺利地完成了，缓存、共享内存这个花了点功夫，还是完成了，

之后是提供用户入口和启动方式，纠结了一小段时间，怎么让它用起来更弱智；

俺选择的做法就是，用户只需在启动时，传入send和receive函数，即可通过这两个自定义的处理函数进行无节操收发数据；

这样做的一个目标是，StacklessIOFQ与用户项目模块耦合性较低，可以在运行时把它分离、更换。

另外一点，stackless socket使用了select，而俺做了一点修改，用epoll；

详细代码就不贴了，模型非常简单，俺的代码风格远不像那些老外的库那么专业，大侠们实现起来估计没啥难度，再敢贴代码就是惹笑话，

不过还是负责地上传了资源：

http://download.csdn.net/detail/zeng_jiang/4342260

留意说明，慎用...

于是，直接公布测试结果：

环境：

cpu：AMD Athlon II X2 240

内存：2G

网卡：Realtek RTL8168C(P)/811C(P)

OS ：Windows XP上跑VirtualBox内的ubuntu

网络环境：本机收发 + 局域网收发

概括：标准的屌丝装备

测试方法：

·建立一定数量的长连接；

·从用户模块（user）接收到第一个包记时a；

·重复：所有长连接同时sendall（for   n）；

·用户模块（user）接收到最后一个包记时b；

·得到时间差c = (b - a)/n；

·有够土方法吧，俺是民工俺认了。

结果：

测试长连接数：5000

局域网测试结果：c的平均成绩是0.05~0.06

本机收发测试结果：c的平均成绩是0.05~0.055

粗糙又微妙的结果...

在这个测试中，网络方面的延时几乎可以忽略，也就是，测试的具体对象，是StacklessIOFQ的数据吞入能力；

用一个情景来描述这次测试结果就是：

--有5000个人同时连着服务器；

--排除掉所有网络延时数据库处理或者其它运算的耗时；

--如果这5000个人在几乎同一个毫秒这么精确的时间片内同时给服务器发包；

--最倒霉的那个人要比最幸运的那个人多耗时0.06秒才能等到自己的包被处理。

这样的结果可接受否？

如果在玩网络游戏的人，应该可以有办法从官方提供的网络延时信息中，看到自己的网络延时，

一般来说，网络状况较好的，延时可以缩小到30~40ms，就算有60ms，也是可以接受的，

也就是说，现在StacklessIOFQ对于5000个请求的瞬时处理，最糟糕的情况下比网络延时还TMD大噢噢噢噢

好吧浪费各位这么多时间看这种东西俺蹲墙角反省去。

提升：

该模块处理效率上其实还有提升空间，毕竟那个测试的模块还新鲜出炉没经过风雨；

自我安慰一句：屌丝装备怎么跟刀片机比，跑纯linux 4核机子至少可以再提高0.01s甚至0.015s的成绩（大概、可能、应该...）；

最重要的，几乎是纯python的要跟c来拼承压，还不如叫俺去跟绿巨人拼力气...

另外：

细心的人会发觉，这个测试，还有那个资源里面的模块，咋的有 I 没O啊；

因为，输出模块俺有了新的想法，打算搞分布式输出；

当然，会在后面花点时间补充上send模块，不过其实策略和 I 模块大同小异，不罗嗦；

其实，因为俺是懒鬼，头脑发热过后，就萎了；

最后，主要是因为兴趣转移到另一些地方去了，于是对于StacklessIOFQ的完善提升和维护，稍稍放后一点吧。

能看到这里的各位，辛苦了。