高性能网络服务器选型比较(EPOLL/Libevent/JAVA mina2)

起因
网上很多关于高性服务器选型的观点，也有很多争议，比如C和JAVA的比较，EPOLL和Libevent的比较，争论不休。包括GLEASY自己提供的中间件，也经常受到不少批评和质疑，收到最多的就是关于使用语言的，GLEASY中间件多数使用JAVA语言，基于MINA2框架，而且我们内部经过大量的压力测试和验证也证明了是性能极高的。关于这一点，在本博客的其它文章中有大量介绍。
不过是否可以百尺杆头，更进一步呢？比如选用C语言和基于C语言的开发库，情况如何呢？
因此，GLEASY架构组做了一系列的实验，来验证当前一些主流的高性能网络服务器开发库的性能比较起来到底如何。

实验数据
实验1：EPOLL(多worker线程，多个线程共享1个epoll,snapshot) C语言
实验2：Libevent N+1线程(one event-loop per thread) C语言
实验3：Mina2(JAVA语言）
实验结果在下面附件中：下载测试文件:http:/file.111com.net/upload/2014/3/a.doc

结论
CPU占用对比图:

TPS对比图：

对两幅图的解释：
1. 从TPS（每秒处理的请求数据上来看），三者没有本质差异，基于JAVA语言的MINA2框架在TPS上绝对不输于C语言EPOLL和LIBEVENT。而且这三个家伙的性能表现都很牛很牛，从图上可以看出，当并发连接在1000左右时，TPS可以达到30万！
2. EPOLL无论在TPS或者CPU占用率方面都占优势。这是预料之中，毕竟LIBEVENT也好，MINA2也好，在LINUX上面，最终使用也是EPOLL机制，所以只要不犯低级错误，原生的EPOLL在性能和CPU消耗方面必然会占优势。
3. LIBEVENT和MINA2都在EPOLL基础上做了大量的封装工作，比如LIBEVENT的buffer event,Mina2的codec，不可避免造成额外的CPU开销。其中基于java语言的mina2在CPU上开销明显大于C语言的其它方案。甚至有接近2倍的差异。
4. 我们在开发功能复杂的服务器应用之时，一些基本的工作必须要做，比如buffer,比如codec，这些工作我们自己做，或者交由libevent或者 mina2来做，始终都要去做，是避免不了的，而且我们自己去实现，本身效率如何也未知。所以我们才会选择使用更上层的封闭，一方面减少工作量，另一方面，避免无关的错误发生。从这一点出发，在做技术选型之时，综合取舍，业务简单但对性能极端要求的场景，可以直接用C语言和EPOLL，业务复杂度高工程较大的需求，可以选用JAVA语言和MINA2。还是那句千年不变的老话，永远没有最好的技术，只有用最适合的技术。别人说的永远只是别人的经验，自己动手尝试证明得到的才是最真实的！

原文:http://rdc.gleasy.com/