BT

Azul’s Zing Elastic Java Runtime for x86 is Generally Available from Today

by Charles Humble on Oct 19, 2010 |

Azul Systems' work is based on technology that can massively scale-up the resources available for Java applications. The two key components of their technology are a pauseless garbage collection algorithm, and a zero-overhead diagnostic/monitoring tool. Until now the pauseless GC algorithm has required dedicated hardware in the form of Azul’s Vega appliances, but Zing, which is generally available from today, comprises a software-only port of Azul's entire technology stack optimized for Intel's x86 processor and AMD. A previous article describes the product in more detail.

Targeting high volume applications where response times are important such as Web portals, trading platforms and e-commerce websites, the need that Azul meets has become increasingly part of the enterprise Java mainstream as applications and users have become more demanding and hardware capabilities greater. George Gould, VP Marketing at Azul, described to InfoQ how three factors - the increasing use of hardware virtualization in the enterprise, the rise of cloud computing through Software and Product as a Service (SaaS/PaaS), and the fact that the JVM has not kept pace with modern hardware capabilities - were forming a "perfect storm" around Java application infrastructure. In the press release that accompanies today's announcement John Abbott, Chief Analyst at The 451 Group, echoes the sentiment:

New business initiatives and technology innovations have outpaced existing Java application infrastructures, increasing pressure on IT organizations to modernize. Existing Java runtimes are being stressed by the needs of high-throughput, business-critical applications, and the adoption of new deployment paradigms such as virtualization and cloud computing. Enterprises must consider new and innovative Java technologies, such as Azul's Zing Java Platform, to achieve better application scalability, elasticity and visibility across a wide range of deployment topologies to meet their business and IT objectives.

Gould observed that virtualization has reached a tipping point in the last year, with the majority of enterprise applications now running on virtualized environments. Azul is well placed to take advantage of this movement, he suggested, since it is specifically designed for virtualization. Parag Patel, vice president of Global Strategic Alliances at VMware, goes further, seeing Zing as a potential catalyst for the virtualization trend

Azul Systems' launch of the Zing Java Platform will help accelerate the adoption of virtualized Java workloads in production environments to drive an IT as a service model. With Zing, all types of Java applications, from small, departmental applications to large, mission- and business-critical applications, can realize the full benefits of virtualization and cloud computing.
Zing Benchmark Graph

We have frequently observed on InfoQ how application architects and developers distribute applications as a way of keeping the heap size smaller to in turn keep performance within acceptable limits. A key aspect of Zing is that by being able to handle heap sizes of several hundred gigabytes with a flat response the runtime allows developers to only distribute when they need to for other engineering reasons. As an example Gil Tene, CTO and Co-founder of Azul Systems, described to InfoQ a benchmark test he had done using the demo application from the Liferay portal 5.23 with the shopping cart JSP modified to perform basic operations.  The portal was running on top of JBoss application server version 5.1.   For hardware Tene used a dual-socket Xeon 5620 at 2.4GHz with 96GB of memory running Fedora C12. The Zing configuration included the VMware 4.0 hypervisor and heaps up to 90+GB. For the native JVM test Tene used the latest commercial JVM with the recommended collector for latency sensitive applications (ConcMarkSweepGC, aka CMS) at heap sizes of 2GB, 3GB, 4GB, 6GB and 20GB. 

The load test used a single JVM, and was based around an SLA of 99.9% of users receiving a response in 5 seconds or less. As shown in the graph to the right, after tuning Tene was able to support around 45 users using the standard JDK before the SLA was broken. With the same hardware and load test using Zing, Tene was able to run around 800 users, with a response time of less than 1 second. Each "transaction" (visit  to shopping cart):

  • Maintains ~20MB of "transaction state" for transaction lifetime
  • Generates ~20MB of (immediately collectable) temp object churn
  • Spends ~300ms blocking (in sleep)

With the load at 800 users, the Zing garbage collector was handling around 3.5GB of garbage/second, with no loss of performance.
 

Zing includes open source components from the Managed Runtime Initiative and, as part of the Zing release for general availability, Azul Systems will contribute updates to the MRI-J OpenJDK and Enhanced Linux projects. As we previously reported, the Managed Runtime Initiative is a collaborative effort to identify, develop and deliver enhanced interfaces and functionality across vertical components of the systems stack in order to improve the execution of managed runtimes, such as Java, Ruby and .NET.

Zing's pricing is based on an annual subscription per server, and starts at around $5,000-$6,000/server/year. A free trial copy can be requested from www.azulsystems.com/trial.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

VMWare's next acquisition? :) by Ashwin Jayaprakash

Is this the beginning of a new "partnership"? :)

The MRI project does not seem to have any activity. No binaries/drops either.

How are Intel/AMD chips able to catch up with Java-specific custom H/w ? by Karthikeyan Manivannan

I read in a previous post about Zing [www.infoq.com/news/2010/06/zing] that commodity hardware is catching up with Azul hardware. How come commodity processors from Intel/AMD able to catch up with Azul's Java-specific custom-hardware ? How come they are able to do better than an architecture which has h/w forwarding pointers and read/write barriers ? Especially since these features speed up Java's biggest bottle-neck - the GC.

Re: How are Intel/AMD chips able to catch up with Java-specific custom H/w by Charles Humble

There's a bit of an explanation here
www.infoq.com/articles/azul_gc_in_detail
The first appendix goes into some detail about how it works

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT