Testimonials

I work for a hedge fund who does extensive algo-trading and high frequency trading. We're anal-retentive when it comes to performance - everything is measured in sub-millisecond latencies.

Netty has played a significant role in our infrastructure - we're using it as our backend communication framework and we wrapped it with our own manager who relays data back and forth between the different stock markets and trading frontends. As for passing messages, we found the combination of Google Protocol Buffers and its support in Netty valuable to no extent, certainly when you consider that our server is Java-based, and clients are most often C#.

While I'm aware there are other frameworks out there, Netty really gives a sense of 'look-no-further'.

• Netty is super-fast. It's fast to the point (and beyond) that I'm more worrying about our code doing something inefficient than my networking framework. In precise measurements not once we've identified Netty as a bottleneck or remotely close to that.
• Protocol Buffers + Netty are your best friends, enabling you design your protocol correctly, even more so if you're planning on a hybrid environment (e.g. Linux / Java as backend, mixed (C#, C++, Python) · hand-held · embedded clients or any combination of them).
• Netty scales.
• Netty is both straightforward to understand, and rather easy to extend and build upon.

Netty proved instrumental in the architecture of a replacement of an existing high-speed server that parses and caches live streaming quotes. Under stress tests, the new server could parse and store in excess of 260,000 quotes/sec, a figure not remotely possible with blocking I/O. Netty's well-documented API, excellent examples and first-class support made development a pleasure and unlocked the power of Java NIO. It is, hands-down, my first choice for a networking library.

Eucalyptus uses Netty as the basis for its new (as of 1.6) web services stack implementation. The stack is a crucial part of Eucalyptus responsible for marshalling user requests, authentication, as well as streaming data (HTTP PUT/GET).

Netty has provided an effective framework (via pipelines) for organizing the varied code paths involved in message processing. Further, as an infrastructure component, Netty manages the select loop for all the sockets and the threading policy for all I/O events. In this role, Netty has delivered performance on the level of 10k concurrent clients meeting a critical performance milestone.

From a design perspective, the Netty pipeline abstraction and its properties of thread safety and dynamic mutability were fundamental to our implementation. A primary challenge facing our web service stack implementation is the variety of different message formats in which requests can be made. Specifically, Eucalyptus supports requests using the spectrum of EC2 API specifications (SOAP, Query, and REST) and two internal SOAP-based protocols. Each of these have different message marshalling and authentication schemes. Additionally, HTTP PUT/GET requests are again different from each of these by consisting of a sequence of requests, or responses, (HTTP chunks) rather than a single request-response pair. Netty's pipeline abstraction serves as the basis for organizing our dynamic protocol stack. Roughly, the stack consists of a static portion, which performs the processing common to all request types, and an unrolling stage, which selects and dynamically expands the pipeline with handlers specific to the request type. In this way, Eucalyptus uses Netty to provide a variety of protocol services via a single socket.

Netty's performance and robustness have been positive both relative to our old web services stack and in absolute terms. Relative to our previous web services stack we have seen improvements across the board in throughput, latency, and scalability for the initial implementation (1.6.1). In particular, the throughput of HTTP GET operations, which leverage Netty's file support, saw a 6x increase. Both latency (time to satisfy a request) and scalability (number of concurrent clients) improved, 2x (50ms) and ~200x+ (up to 4k concurrent clients w/ sub-20sec response time). Moreover, our stack has been subsequently been improved with an eye towards performance and yielded further improvements in latency (down to ~5ms) and concurrency (up to 10k w/ sub-20sec response time). Using Netty as the basis for our web services stack has brought a new level of performance and scale to Eucalyptus.

I needed to develop a Flash game server which can effortlessly control many simultaneous Flash clients. I started out with Apache MINA. Although it worked fine, its development pace and bug fix was slow. I decided early on to make the jump to Netty because of the overall quality of the code, documentation and design. Switching to Netty was one of the best decisions in my project because Netty made it possible to keep the network logic simple and robust while keeping good performance.

Although the design of the Flash game server has been changed significantly since its beginning, Netty kept up easily with my changing demands. Netty provided whatever I wanted and did it very well.

Needless to say that Netty has a lot of 'power', it is also very pleasant and easy to use. Thank you Trustin for this gem of Java library. I wish more libraries were as solid as Netty.

Trustin et al, you have delivered an excellent framework that demystified Java NIO, providing me with an elegant no nonsense API. My application, an HTTP proxy server with substitution exposing nearly 1700 external partner web sites though a single domain has been running problem free since August 2009.

As you can imagine, dealing with so many external HTTP server environments presented surprises. Netty was unrattled, providing seamless flexibility so we could accommodate each condition.

During development testing, the library has exceeded our expectations; now in production two load balanced servers easily serve thousands of concurrent customers without complaint. Each server, which has two 3GHz dual-core Xeon processors and 16GB RAM, has peaked at over 22,000 messages per second, with a throughput which has exceeded 120MB per second combined.

We found memory and CPU is nominal even during peak conditions. Given this, we decided to relax application developed governors that throttle activity based on I/O throughput and memory.

I have been assigned the task of making our EMS server more scalable such that it can handle twice as much network elements as it currently does, keeping all functionality intact, using the same or lesser resources (CPU and RAM), meanwhile keeping the performance at par. When we started evaluating the various framework, we were looking for something that met the following criteria:

• At least 1 Major stable release
• Easy to understand architecture and APIs
• Well-documented Javadoc, user guide and examples
• Built in SSL support
• Shorter release cycle for faster turnaround on request for new features

(...) It was very easy to develop the application with Netty, due to its intuitive APIs. The support from Trustin and Frederic was always very quick and accurate, which is very important for newbies like me. The turnaround time on reported issues on Netty is amazingly short, which makes Netty the right choice for me.

Currently, I have ported my Fault Application from old I/O to NIO and reaping the benefits of Netty, a look at CPU and memory makes the whole dev team smile. Thanks Netty community, one and all, for the smiles :)

Working on a telecom project, I was asked to develop a server side MSRP protocol stack to enable Chat, IM and Push to Share features for our product. Having little knowledge of Java NIO features, (...) I expected a steep learning curve. The Netty user guide got me up to speed in no time. The asynchronous, event driven model made perfect sense for my requirement. I finished the core stack implementation in 3 days flat. I implementated a custom codec to validate and decode / encode MSRP messages. The rest of it was mostly infrastructure code related to session management, connection management and channel handling. In all I wrote probably not more than eight classes. The whole stuff works like a charm with so little effort. Keep up the good work!

I'm the maintainer of jmemcached. Up until yesterday I was using Apache MINA. I spent one day switching over to Netty. I must say I'm happier. Things I liked:

• Clearer documentation
• A saner API in many places, with better defaults
• More active development cycle.

After switching to Netty I had a 20% improvement in overall performance, and the code was much simpler. Now, much of the improvement in performance may have been because I had a chance to rewrite the decoder and likely produced better code, but that is also a good argument for Netty.

I have recently conducted performance and scalability tests with Netty 3.1.0.BETA2 for embedded HTTP server. Our product is currently under lab testing and is due for production soon. Using the Netty asynchronous HTTP API, we were able to support requests from 10000 simultaneous clients doing HTTP POST every 20 secs with an average 500 requests/sec on a 1-CPU, 1-GB RAM machine. Here's how Netty scored:

Netty API was very easy to use and documents and examples were more than adequate to switch from AsyncWeb to Netty in 1 day! We had tried to evaluate Grizzly also but Netty's API was simpler to understand and adopt.

Netty framework seems to be actively supported and quite stable. Apache, for example, is doing active development of the core MINA API but ever since taking over the AsyncWeb framework from Safehaus, there has been no official release for this HTTP framework from Apache. The Safehaus-version of AsyncWeb is no longer supported but is still the only official and stable release.

Compared to the Safehaus-version of AsyncWeb+MINA0.8, with Netty, our application had a much better CPU and memory graph. With that, we were able to support at least 2000 more clients.

Trustin et al, thank you very much for producing this excellent library that has allowed me to focus on my application while giving me the benefits of NIO for "free" through an event-based programming model, which was a perfect fit for my application. As of February 12th 2009, the application has been running in production since November 16th 2008 and allows us to maintain long-lived, stateful client connections that communicate with each other in an asynchronous manner.

During our lab testing, the library has displayed excellent performance characteristics, allowing us to service 50,000+ messages per second from approximately 30,000 connected clients on a commodity Intel server costing approximately $850. Even at that throughput level we were bandwidth-, not CPU-, limited on our server. In addition to the positive performance tests, our JVM has not been restarted since the initial go-live.