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.
Improvements to 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.
Room for Improvement
The profiling tools included with Zing lag behind those available for Oracle's Java implementation.
Use of 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.
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.
Customer Service and Technical Support
It's very good. Technical Support
It's very good.
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.
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.
Our implementation was a collaboration between LMAX Exchange and Azul. Azul's technical expertise is very good and their help was invaluable.
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.
Other Solutions Considered
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.
Follow the supplied tuning guidelines and ensure that the tunings are correctly applied before assessing performance.
Disclosure: My company has a business relationship with this vendor other than being a customer: We have actively tried to foster a collaborative technical relationship with Azul. We have shared lots of code, performance test results and anything else we are legally allowed to in order to help Azul make Zing a better product. In addition to the vendor-customer relationship some of our people have ended up working on side projects together and doing joint talks at conferences, but that is more a reflection of common interests than anything else.
Nov 05 2015