在 Twitter,Netty 4 GC 开销降为五分之一

  • Matt Raible
  • 马德奎

2013 年 11 月 12 日

话题:Java语言 & 开发

Netty 项目在 7 月份发布了 Netty 4 的第一个版本,其性能的显著提升主要来源于垃圾收集开销的降低。在 Twitter,Netty 4 经过完善已经获得了 5 倍的性能提升,但也有一些代价。

Netty 项目创始人和 Twitter 软件工程师Trustin Lee从 2003 年开始就一直编写网络应用程序框架。Netty 第一次公开发布是在2004 年 6 月,其项目主页这样描述它,“一种异步事件驱动的网络应用程序框架,用于可维护的高性能协议服务器和客户端的快速开发。”

Lee 在博文“Netty 4 在 Twitter:降低 GC 开销”中写道,Twitter 在许多地方使用 Netty 实现联网功能:

  • Finagle是我们的协议无关的 RPC 系统,用于实现大部分内部服务,如搜索,它的传输层建立在 Netty 上。
  • TFE(Twitter 前端)是我们专有的填鸭式反向代理,它使用 Netty 为大部分面向公众的 HTTP 和SPDY流量提供服务。
  • Cloudhopper每月用 Netty 向遍布世界各地数以百计的运营商发送数十亿条短信息。

Netty 包含一个反应堆模式的实现,它同时也是Play 框架的核心。Play、Grails 和许多其它 Web 框架都采用一种WAR-less Web 应用程序模式,它允许与底层 HTTP 服务器更紧密地集成。使用内部包含像 Netty 这种框架的服务器,异步编程会简单很多。异步编程和非阻塞 I/O 是“响应宣言(The Reactive Manifesto)”的核心。InfoQ 在“新兴趋势:响应式编程”中报道了这一新兴模式。

Netty 3 使用 Java 对象表示 I/O 事件。Lee 谈道:

这样简单,但会产生大量的垃圾,尤其是在我们这样的规模下。Netty 4 在新版本中对此做出了更改,取代生存周期短的事件对象,而以定义在生存周期长的通道对象上的方法处理 I/O 事件。它还有一个使用池的专用缓冲区分配器。

……每当收到新信息或者用户发送信息到远程端,Netty 3 均会创建一个新的堆缓冲区。这意味着,对应每一个新的缓冲区,都会有一个‘new byte[capacity]’。这些缓冲区会导致 GC 压力,并消耗内存带宽:为了安全起见,新的字节数组分配时会用零填充,这会消耗内存带宽。然而,用零填充的数组很可能会再次用实际的数据填充,这又会消耗同样的内存带宽。如果 Java 虚拟机(JVM)提供了创建新字节数组而又无需用零填充的方式,那么我们本来就可以将内存带宽消耗减少 50%,但是目前没有那样一种方式。

在 Netty 4 中,代码定义了粒度更细的 API,用来处理不同的事件类型,而不是创建事件对象。它还实现了一个新缓冲池,那是一个纯 Java 版本的jemalloc(Facebook 也在用)。现在,Netty 不会再因为用零填充缓冲区而浪费内存带宽了。不过,由于它不依赖于 GC,开发人员需要小心内存泄漏。如果忘记在处理程序中释放缓冲区,那么内存使用率会无限地增长。

这些变化没有向后兼容 Netty 3,但其垃圾生成速度是原来的 1/5,而垃圾清理速度快了 5 倍。

Lee 写道:

我们比较了两个分别建立在 Netty 3 和 4 基础上echo协议服务器。(Echo 非常简单,这样,任何垃圾的产生都是 Netty 的原因,而不是协议的原因)。我使它们服务于相同的分布式 echo 协议客户端,来自这些客户端的 16384 个并发连接重复发送 256 字节的随机负载,几乎使千兆以太网饱和。

根据测试结果,Netty 4:

  • GC 中断频率是原来的 1/5:45.5 vs. 9.2 次 / 分钟
  • 垃圾生成速度是原来的 1/5:207.11 vs 41.81 MiB/ 秒

Lee 提到,在 Twitter 中采用 Netty 4 还有一些障碍,那就是缓冲区泄漏和核心复杂。该项目希望增加更多功能,包括 HTTP/2、异步 DNS 解析以及客户端 HTTP 和 SOCKS 代理支持。

Yahoo 工程部门有一篇类似的文章,内容是关于 Netty 如何帮助他们成倍地提升Storm 集群的速度。在名为“Netty 让 Storm 飞速运行”的文章中,Bobby Evans 写道:

在雅虎,我们都是用自己的产品进行开发。在将 Netty 作为 Storm 集群的默认消息层之前,我需要一些数据来确认,它与当前的默认消息层 zeromq 相比怎么样。要做到这一点,我需要一个能够使 Storm 消息层达到极限的基准测试程序,因此,我写了一个。那是一个简单的高速测试,用于确认 Storm 在不同的 Bolt 和 Spout 之间推送消息有多快。它允许同时启动多个具有不同复杂度的 Topology 来发送定长消息。

Evans 指出,在小规模测试中(没有资源冲突),Netty 比 zeromq 更快(40-100%)。在大规模测试中,它也遇到了性能问题,但减少了解决问题的线程数。

对于大量短消息而言,Netty 的默认设置并不是很好,即使该节点上只有它自己在运行。但是,当把它限制在单线程上,我们每秒能够获得比 zeromq 多 85% 到 111% 的消息,之后网络再次饱和。

Evans 指出,Netty 现在是 Yahoo Storm 集群的默认消息层。

Netty 4 的改进对许多开源项目都大有益处。该框架有一个长长的相关项目列表,包括AkkaApache JamesHornetQVert.x,这里仅举这几例。要了解更多关于 Netty 4 的信息,请查看netty.ioLee 的博文

查看英文原文:Netty 4 Reduces GC Overhead by 5x at Twitter

Java语言 & 开发