Azul Zing Reviews

As a large scale high performance trading platform serving the high frequency trading community, latency has always been critical for our clients.

Before using Azul/Zing JVM, we had to spend a lot of effort tuning our JVM GC and profiling our application to minimize latency, which is sometimes very unpredictable due to Java GC. Azul/Zing solved our Java GC problem.

With minimal effort, Zing has helped us improve our latency performance dramatically. There are no more jitters or pauses that used to require hours or days of research to resolve in our production environment. Zing has freed our development resources to focus on our core business.

Like every other great product, there is always something that can be improved. Although Azul claims to have a fast warmup, we still experience higher latency for the first trade when our system starts up on Sundays. It would be extremely helpful if Zing JVM can learn to warmup that code path or print some insights of the path that lead to a solution. The other feature we find very useful, but would like to see some improvement on, is the Azul’s Java profiling tool.

The ROI is excellent.

Overall, we think Azul/Zing is a great product for low latency, mission-critical applications.

The pauseless garbage collection is the primary feature. ReadyNow is becoming more and more important.

As we provide real-time, low-latency trading solutions, any 'pause' in the application flow can cause serious financial risks to our customers. We used to spend numerous hours tuning each release, and then each customer site, in order to minimize the length of pauses in the standard Java runtime. With Zing, we've now been able to re-allocate those tuning resources to general product development.

The performance monitoring is not sufficient for certain types of performance optimization and problem diagnosis. Development often needs to run the application under a different JVM in order to perform these functions.

I have used it for four years+.

We have encounter stability issues and that has been a source of frustration at times. Azul has been very responsive in correcting the issues, but when dealing with mission-critical enterprise software - which we deliver - the core/system-level components need to have near-perfect reliability or the entire system is affected.

We have not hit any scalability limits, nor do we have concerns in this area.

The Zing software is very sophisticated, so even Azul's first-line technical support personnel are extremely knowledgeable, but often due to the exacting nature of our requirements, we are referred to Level 2 and beyond. Azul is an engineering company, and in our view, employs highly qualified engineers.

We use to use the Oracle JVM and switched due to the application pauses due to GC. Even the latest Oracle/OpenJDK G1 collector does not come close to the performance of Zing.

Initial setup was very straightforward, almost a drop-in replacement for the Oracle JVM. The Azul marketing position of 'zero configuration' is a bit of a stretch in our case, since in order to achieve optimum performance, some configuration and tuning are required.

Azul Zing can be expensive to deploy based on the environment, but for certain types of installations, there is no other option.

Before choosing this product, we reviewed the Oracle, OpenJDK and IBM J9 virtual machines.

For many classes of applications, alternative JVMs might provide sufficient low-pause operation that Zing is not required. That being said, we don't use the 'ultra large heap capability' of Zing that many applications would benefit from.

As a large scale high performance trading platform serving the high frequency trading community, latency has always been critical for our clients. Before using Azul/Zing JVM, we have had to spend a lot of effort tuning our JVM GC and profiling our application to minimize latency, which is sometimes very unpredictable due to Java GC. Azul/Zing solved our Java GC problem. With minimal effort, Zing has helped us improve our latency performance dramatically. There are no more jitters or pauses that used to require hours or days of research to resolve in our production environment. Zing has freed our development resources to focus on our core business.

Like every other great product, there is always something that can be improved. Although Azul claims to have a fast warmup, we still experience higher latency for the first trade when our system starts up on Sundays. It would be extremely helpful if Zing JVM can learn to warmup that code path or print some insights of the path that lead to a solution. The other feature we find very useful but would like to see some improvement on is the Azul’s Java profiling tool.

Overall, we think Azul/Zing is a great product for low latency mission critical applications. The ROI is excellent.

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.

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.

The profiling tools included with Zing lag behind those available for Oracle's Java implementation.

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.

No issues encountered.

No issues encountered.

It's very good.

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.

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.

Pause-less JVM garbage collection on JVMs with heaps in the hundreds of gigabytes is the feature I find most valuable.

We use the Zing JVM to deliver Solr search capabilities to our clients. Without it, we would need a team of full-time engineers to continually shard and re-shard the indices so that small heaps are used to avoid pausing during garbage collection.

It is extremely expensive. It is the most expensive single product that our company consumes.

I've used it for three years.

No issues encountered.

The Zing JVM, once installed properly and sized appropriately, is highly stable.

No issues encountered.

It's fantastic.

It's top notch.

All other solutions were open-source JVMs and none of them had the features of the Zing JVM.

It is moderately complex, but the deployment documentation is done very well which simplified initial setup greatly.

It was done in-house.

This is a product that is expensive, but for this product almost certainly we get what we pay for.

No other JVM on the market even comes close to competing with the Azul Zing.

Make sure you really need it, and if you do need it, it will save your life.

The non-stop garbage collector (C4 - Continuously Concurrent Compacting Collector) is the most valuable feature.

It has made it possible to spend time on developing new functions rather than optimizing old ones.

If possible, a better way to pinpoint the source line of a memory leak.

Since August 2013, hence two years.

No issues encountered.

No issues encountered.

No issues encountered.

It's good.

It's good.

We switched due to performance issues

It was straightforward because of good initial help from Azul.

We did it in-house.

• Oracle JVM
• JRockit

Just give it a try.

• GC Pause times are maintained in low milliseconds. This is beneficial for applications with high volume, high memory allocation rate, and a high memory footprint, (I would say >2.5gb of max heap). It also increases throughput by approximately 20-25% as compared to Oracle Java Development Kit, based on some tests that I have done with real applications
• Azul engineering cleans up Oracle Java Development Kit bugs before GA release of the product, so you will get less bugs
• The engineering support is very qualified, so they can help you diagnose code level issues and provide recommendations. Zing has free tools to get you to the root of many applications problems, like memory leaks, thread blockades, system limitations, etc.
• Support lifecycle is almost unlimited. Oracle Java Development Kit's lifecycle is three years, after that you have to buy a “commercial license” which is expensive

We use it on highly visible applications, with application characteristics described above.

I have been so happy with it. Since we upgraded, we have never had a need to even call support. So I have no recommendations, other than try to certify Zing with more vendors.

I've used Zing for over two years. This was an upgrade from its predecessor which I had used for about six to seven years.

No issues encountered, but it was just an upgrade.

No issues encountered.

No issues encountered.

9/10, it's the best of any vendor.

9/10, it's the best of any vendor. Every now and then, I touch base with support to see if I need to make any adjustments based on new developments.

We were trying to scale horizontally as workload increased, but there is a limit to that. Zing can absorb a lot more workload, by just adding more memory and/or CPUs, which is easer then provisioning more and more servers.

It is not bad, but it would be great to engage Azul to educate you while you are doing it yourself. There is somethings to learn about this new and exciting technology.

I got some help from support and sales engineering during a POC. They provided me instructions and answered educational questions.

The license price is almost the same as other vendors, but you can cut the cost by running more applications on the same four socket server.

The other option would have been Oracle Java Development Kit G1GC. We tried it, but I was not convinced. However, it does have a potential in somecases, but you need to stress test the application to be sure is a good fit.

Performance of the JVM, especially the C4 Pauseless Garbage Collection, for continuous application execution is the most valuable feature.

Also, some of the support tooling (zvision, gcloganalyser, azulinspector) is valuable.

Improvements on the tooling for tuning the applications is needed.

We had one issue reported and it was solved by Azul's support team.

An issue happened in a production environment that stopped the system.

Not in testing.

5/5.

4.5/5.

We previously used Oracle JVM.

It was straightforward.

We implemented it in-house.

The licensing over non-production environments considerably affects the cost of our solution as a software vendor.

Oracle JVM