What is most valuable?
The most important Zing feature for LMAX Exchange is the C4 garbage collector. C4 effectively does continuous garbage collection and for LMAXExchange that means less latency jitter. Latency is a big deal for us and while low latency is important, predictable latency is also a requirement for our customers. Zing doesn't need to force periodic safepoints during normal operation, so assuming that you don't have any other sources of jitter in your program, you'll get a flatter latency profile with out-of-the-box behaviour.
How has it helped my organization?
Zing has completely solved the garbage collection problem for us. We no longer need to concern ourselves with tuning the garbage collector or coding around it. This has saved us an enormous amount in terms of potential opportunity cost and allows us to spend more time on the business problems that really matter. Not having to butcher our code to make it garbage free has probably also helped us to retain a high level of productivity and a low level of defects.
What needs improvement?
The profiling tools included with Zing lag behind those available for Oracle's Java implementation.
For how long have I used the solution?
LMAX Exchange has been an Azul customer for just under three years although we also did some product evaluation for a few months before that.
What was my experience with deployment of the solution?
It took us a long time in our performance testing environment to configure the operating system correctly to get the best out of the product.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
How are customer service and technical support?
It's very good. Technical Support
It's very good.
Which solution did I use previously and why did I switch?
We used Oracle's Java implementation and switched because upgrading from v6 to v7 led to significant performance regression. Also, we had reached a latency floor that we were unable to get past without a better garbage collector or a significant re-write of the implementation of our software.
How was the initial setup?
It is more complex than a comparable product, e.g. Oracle's Java. Zing requires a kernel module to be installed on all of the Linux systems that it runs. This is slightly tricky as a normal Java install does not require administrator privileges, where as Zing does. It also required a fair bit of Linux tuning and testing to get the best performance out of it. Also, we opted to use license files rather than a license server so that added some complexity to deployment.
What about the implementation team?
Our implementation was a collaboration between LMAX Exchange and Azul. Azul's technical expertise is very good and their help was invaluable.
What was our ROI?
It's not particularly easy to estimate ROI as the cost for LMAX Exchange of not going with Zing would have have been partly tying up most of the development team for a long period of time and partly the opportunity cost to the business of missing out on a lot of revenue generating features. I think everyone at LMAX Exchange is convinced that our investment in Zing has been completely justified and that the product has easily paid for itself and then some.
Which other solutions did I evaluate?
Zing was really the only game in town if we wanted to stay with Java and improve our latency through third party technology. Changing language even for part of our codebase is not an option we have considered seriously so far. We gave the move to garbage free Java some consideration but not that much.
What other advice do I have?
Follow the supplied tuning guidelines and ensure that the tunings are correctly applied before assessing performance.