转载

Netty高性能编程备忘录（上）

网上赞扬Netty高性能的文章不要太多，但如何利用Netty写出高性能网络应用的文章却甚少，此文权当抛砖引玉。

估计此文很快就要被拍砖然后修改，因此转载请保持原文链接:

http://calvin1978.blogcn.com/articles/netty-performance.html ，否则视为侵权。。。

参考资料：

Netty Best Practices a.k.a Faster == Better by Norman Maurer，Netty核心开发
Netty高性能之道 by 李林锋，《Netty权威指南》作者
Netty系列之Netty百万级推送服务设计要点 by 李林锋
用Netty开发中间件：高并发性能优化

1. 连接篇

1.1 Netty Native

Netty Native 是由Twitter将Tomcat Native的移植过来，用C++编写JNI调用的Socket Transport。

经测试，Netty Native的确比JDK NIO更省CPU。

也许有人问，JDK的NIO也用EPOLL啊，大家有什么不同？ Norman Maurer这么说的：

* Netty的 epoll transport使用 epoll edge-triggered 而 java的 nio 使用 level-triggered.

* C++的代码，更少GC，更少synchronized。

* netty的epoll transport 暴露了更多的配置参数。

第一条没看懂，反正测试结果的确更快省更CPU。

用法倒是简单，只要把NioEventLoopGrouph等几个类改名成EpollEventLoopGroup之类即可，详见Netty的官方文档1 ，文档2

但要注意，首先它跟OS相关，而且基于GLIBC2.10编译，而CentOS 5.8就只有GLIBC2.5（别问为什么，厂大怪事多，我厂就是还有些CentOS5.8的机器），所以最好还是不要狠狠的直接全文搜索替换，而是用System.getProperty(“os.name”) 和 System.getProperty(“os.version”) 取出操作系统名称与版本，做成一个开关。

另外，Netty很多版本都有修复Netty Native相关的bug，看得人心里发毛，好在最近的版本终于不再说了，所以要用就用Netty的新版。

最后，Netty Native还包含了Google的boringssl(A fork of OpenSSL)，JDK的原生SSL实现比较慢而且GC甚多，而大家把SSL Provider配置成OpenSSL时，又要担心操作系统有没装OpenSSL，或者版本会不会太旧。现在好了。

1.2 异步连接，异步传输，告别Commons Pool

使用NIO最牛头不对马嘴的事情就是，给它配一个类似Commons Pool这样，有借有还的连接池。

因为NIO的本质就是轮询事件，不阻塞不独占，所以无论做什么事情，根本不需要独占一条连接，不需要把它借出去，再还回池里。Netty现在也有个ChannelPool了，不过我还是不知道有什么用。一来连接池出入之间有锁，二来并发请求一多就要无厘头的狂建连接，到连接池上限时还要白白等待别人释放连接，而这在NIO的世界里其实毫无必要。

所以，建议直接建一个连接数组，随机到哪个连接就用哪个连接发数据。如果数组里的某个连接还没建立或者已经失效，那就重新建立连接。

顺便说一句，异步的世界里，连建立连接的过程也是异步的，主线程不要等在建连接上，而是把发送的动作封成一个ChannelCallback，等连接建立了，再回调它发送数据，避免因为连接建立的缓慢或网络根本不通，把线程都堵塞了。

1.3 最佳连接数：一条连接打天下？还有传说中的海量连接？

NIO这么神奇，有一种做法是只建一条连接，如Memcached的客户端SpyMemcached。还有一种是既然你能支持海量连接，几千几万的，那我就无节制的可劲的建了。

测试表明，一条连接有瓶颈，毕竟只用到了一个CPU核。海量连接，CPU和内存在燃烧。。。。

那最佳连接数是传说中的CPU核数么？依然不是。

一切还是看你的场景，连接数在满足传输吞吐量的情况下，越少越好。

举个例子，在我的Proxy测试场景里：

2条连接时，只能有40k QPS。
48条连接，升到62k QPS，CPU烧了28%
4条连接，QPS反而上升到68k ，而且CPU降到20%。

1.4 Channel参数设定

1.4.1 TCP/Socket参数

TCP/Socket的大路设置，无非 SO_REUSEADDR， TCP_NODELAY， SO_KEEPALIVE 。

另外还有SO_LINGER ， SO_TIMEOUT, SO_BACKLOG, SO_SNDBUF, SO_RCVBUF ，建议缓冲区大小不要显式设定覆盖内核参数里设定的动态适配。

而用了Native后还有其他的配置，比如TCP_CORK和KeepAlive包发送的时间间隔（默认2小时），在Java的标准Socket里居然只能设是否KeepAlive而KeepAlive的其他参数要通过内核参数设定，比较奇葩，详见 EpoolSocketChannelConfig的JavaDoc 。

所有这些参数的含义，不一一描述了，自己搜索，比如 Linux下高性能网络编程中的几个TCP/IP选项。

1.4.2 Netty参数

CONNECT_TIMEOUT_MILLIS，Netty自己起一个定时任务来监控建立连接是否超时，默认30秒太长谁也受不了，一般会弄短它。

WRITE_BUFFER_HIGH_WATER_MARK 与 WRITE_BUFFER_LOW_WATER_MARK是两个流控的参数，默认值分别为32*2K与32K.。如果在writer buffet里排队准备输出的字节超过上限，Channel就不是writable的，NIO的事件轮询里就会把它摘掉，直到它低于32k才重新变回writable。建议没有足够的测试不要动它。