How Micro is Payara Micro?

Photo of Steve Millidge by Steve Millidge
4_fish_1_resized.jpgElastic Middleware describes middleware capable of expanding and contracting quickly on demand. A common example is the ability for an application server cluster to quickly expand the number of cluster nodes to meet an unpredicted surge in the level of traffic.

The whole philosophy of Payara Micro is to turn the idea of application servers on its head and change the perception that they are large, complex and unwieldy environments for building server side applications. So as part of our development we've done some analysis of how small the core runtime of Payara Micro is.

If you are familiar with the Eclipse Memory Analyzer Toolkit ; a fantastic tool that every Java developer should be aware of; you'll know that it essentially analyzes JVM heap dumps to rapidly tell you which objects are holding the most memory in your JVM. As part of our Payara Micro tuning we recently ran MAT across a “raw” Payara Micro instance i.e. a server with clustering enabled but no applications deployed to determine the heap used and to look for tuning opportunities. So to get the data we fired up Payara Micro;
java -jar payara-micro.jar
We then fired up jvisualvm and hit the “Heap Dump” button on the “Monitor” tab

jvisualvm

Opened up the heap dump in MAT and here's the results;

MAT Results

As you can see Payara Micro only uses 17Mb of JVM Heap when running raw. Now that is micro!Why does that matter? Well a smaller core runtime leaves more memory available for your applications to use. It means less garbage collections for better performance. It means higher densities of deployments on cloud environments.It also means if you use the built in JSR 107 Caching capabilities you can store more data in memory across your Payara Micro Grid.

Now you may be thinking that's all well and good but what about when running an application. So we also analysed the heap usage after we'd deployed a recent demonstration application we created for NetBeans day.The demo application isn't complicated but consists of an entity bean, session bean, JAX-RS service; embedded Derby and a servlet and the NetBeans RESTful service test application so it does initialize and use most of the runtime components  and containers people use. The war was approximately 300Kb in size.

Diagram

If you've never seen the NetBeans Test app for RESTful web services it's shown below for this application.

NetBeans Test app

So here's the updated MAT results;

MAT results

25.6MB of heap used. We think this is pretty good. We hope you do to! We'd love you try out your applications and let us know the results.

Comments