Go to file
Jakob Buchgraber 6fd0a0c55f Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600
Motivation:

We noticed that the headers implementation in Netty for HTTP/2 uses quite a lot of memory
and that also at least the performance of randomly accessing a header is quite poor. The main
concern however was memory usage, as profiling has shown that a DefaultHttp2Headers
not only use a lot of memory it also wastes a lot due to the underlying hashmaps having
to be resized potentially several times as new headers are being inserted.

This is tracked as issue #3600.

Modifications:
We redesigned the DefaultHeaders to simply take a Map object in its constructor and
reimplemented the class using only the Map primitives. That way the implementation
is very concise and hopefully easy to understand and it allows each concrete headers
implementation to provide its own map or to even use a different headers implementation
for processing requests and writing responses i.e. incoming headers need to provide
fast random access while outgoing headers need fast insertion and fast iteration. The
new implementation can support this with hardly any code changes. It also comes
with the advantage that if the Netty project decides to add a third party collections library
as a dependency, one can simply plug in one of those very fast and memory efficient map
implementations and get faster and smaller headers for free.

For now, we are using the JDK's TreeMap for HTTP and HTTP/2 default headers.

Result:

- Significantly fewer lines of code in the implementation. While the total commit is still
  roughly 400 lines less, the actual implementation is a lot less. I just added some more
  tests and microbenchmarks.

- Overall performance is up. The current implementation should be significantly faster
  for insertion and retrieval. However, it is slower when it comes to iteration. There is simply
  no way a TreeMap can have the same iteration performance as a linked list (as used in the
  current headers implementation). That's totally fine though, because when looking at the
  benchmark results @ejona86 pointed out that the performance of the headers is completely
  dominated by insertion, that is insertion is so significantly faster in the new implementation
  that it does make up for several times the iteration speed. You can't iterate what you haven't
  inserted. I am demonstrating that in this spreadsheet [1]. (Actually, iteration performance is
  only down for HTTP, it's significantly improved for HTTP/2).

- Memory is down. The implementation with TreeMap uses on avg ~30% less memory. It also does not
  produce any garbage while being resized. In load tests for GRPC we have seen a memory reduction
  of up to 1.2KB per RPC. I summarized the memory improvements in this spreadsheet [1]. The data
  was generated by [2] using JOL.

- While it was my original intend to only improve the memory usage for HTTP/2, it should be similarly
  improved for HTTP, SPDY and STOMP as they all share a common implementation.

[1] https://docs.google.com/spreadsheets/d/1ck3RQklyzEcCLlyJoqDXPCWRGVUuS-ArZf0etSXLVDQ/edit#gid=0
[2] https://gist.github.com/buchgr/4458a8bdb51dd58c82b4
2015-08-04 17:12:24 -07:00
all [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
buffer [#3896] Unpooled.copiedBuffer(ByteBuffer) and copiedBuffer(ByteBuffer...) is not thread-safe. 2015-07-07 08:38:37 +02:00
codec Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
codec-dns [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-haproxy Add ProtocolDetectionResult and use it in HAProxyMessageDecoder for allow detect HAProxy protocol. 2015-06-23 08:59:07 +02:00
codec-http Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
codec-http2 Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
codec-memcache [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-mqtt MqttEncoder build failure 2015-07-30 10:20:01 -07:00
codec-socks [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
codec-stomp Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
codec-xml [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
common Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
example Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
handler [#3968] Disallow pass-through of non ByteBufs in SslHandler 2015-07-22 13:31:33 +02:00
handler-proxy [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
license Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:38:11 +02:00
microbench Faster and more memory efficient headers for HTTP, HTTP/2, STOMP and SPYD. Fixes #3600 2015-08-04 17:12:24 -07:00
resolver [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
resolver-dns DnsResolver.resolve(...) fails when ipaddress is used. 2015-07-18 17:14:05 +02:00
tarball [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
testsuite [#3987] Remove RC4 from default ciphers. 2015-07-22 13:29:43 +02:00
testsuite-osgi [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
transport Correctly count acquired channels when timeout occurs in FixedChannelPool 2015-07-30 07:55:46 +02:00
transport-native-epoll Add support for IP_FREEBIND when using native transport 2015-07-30 20:57:53 +02:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
transport-udt [maven-release-plugin] prepare for next development iteration 2015-05-07 14:21:08 -04:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Add JVM crash logs to .gitignore 2014-05-18 21:36:54 +09:00
.travis.yml Travis CI branch whitelisting 2013-03-11 09:55:43 +09:00
CONTRIBUTING.md Move the pull request guide to the developer guide 2014-03-12 13:13:58 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:38:11 +02:00
pom.xml Correctly handle errors when using OpenSSL 2015-06-21 21:06:42 +02:00
README.md Add a link to the 'native transports' page 2014-07-21 12:54:24 -07:00
run-example.sh Add HTTP/2 Netty tiles example 2015-05-18 14:16:54 -07:00

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

How to build

For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.

You require the following to build Netty:

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.

Branches to look

The 'master' branch is where the development of the latest major version lives on. The development of all other versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.