73dfd7c01b
Motiviation: ChannelOuboundBuffer uses often too much memory. This is especially a problem if you want to serve a lot of connections. This is due the fact that it uses 2 arrays internally. One if used as a circular buffer and store the Entries that are never released (ChannelOutboundBuffer is pooled) and one is used to hold the ByteBuffers that are used for gathering writes. Modifications: Rewrite ChannelOutboundBuffer to remove these two arrays by: - Make Entry recyclable and use it as linked Node - Remove the circular buffer which was used for the Entries as we use a Linked-List like structure now - Remove the array that did hold the ByteBuffers and replace it by an ByteBuffer array that is hold by a FastThreadLocal. We use a fixed capacity of 1024 here which is fine as we share these anyway. - ChannelOuboundBuffer is not recyclable anymore as it is now a "light-weight" object. We recycle the internally used Entries instead. Result: Less memory footprint and resource usage. Performance seems to be a bit better but most likely as we not need to expand any arrays anymore. Benchmark before change: [nmaurer@xxx]~% wrk/wrk -H 'Host: localhost' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Connection: keep-alive' -d 120 -c 256 -t 16 --pipeline 256 http://xxx:8080/plaintext Running 2m test @ http://xxx:8080/plaintext 16 threads and 256 connections Thread Stats Avg Stdev Max +/- Stdev Latency 26.88ms 67.47ms 1.26s 97.97% Req/Sec 191.81k 28.22k 255.63k 83.86% 364806639 requests in 2.00m, 48.92GB read Requests/sec: 3040101.23 Transfer/sec: 417.49MB Benchmark after change: [nmaurer@xxx]~% wrk/wrk -H 'Host: localhost' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Connection: keep-alive' -d 120 -c 256 -t 16 --pipeline 256 http://xxx:8080/plaintext Running 2m test @ http://xxx:8080/plaintext 16 threads and 256 connections Thread Stats Avg Stdev Max +/- Stdev Latency 22.22ms 17.22ms 301.77ms 90.13% Req/Sec 194.98k 41.98k 328.38k 70.50% 371816023 requests in 2.00m, 49.86GB read Requests/sec: 3098461.44 Transfer/sec: 425.51MB |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-http | ||
| codec-socks | ||
| common | ||
| example | ||
| handler | ||
| license | ||
| microbench | ||
| tarball | ||
| testsuite | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
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:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
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 major versions takes place in each branch whose name is identical to its major version number. For example, the development of 3.x and 4.x resides in the branch '3' and the branch '4' respectively.