Spring chickens and spring boots!



One of the widely wasted resources in the world today is Memory. Due to inefficient programming, a surprising (sometimes ‘shocking’) amount of memory is wasted. We see this pattern repeated in several enterprise applications. To prove this case, we conducted a small study.

You may also like: How to Prevent Your Java Collections From Wasting Memory

We analyzed the famous spring boot pet clinic application to see how much memory it is wasting. This application has been designed by the community to show how the spring application framework can be used to build simple but powerful database-oriented applications.

Environment

Spring Boot 2.1.4.RELEASE

Java SDK 1.8

Tomcat 8.5.20

MySQL 5.7.26 with MySQL Connector/J 8.0.15

Stress Test

We used Apache JMeter, a popular open-source load testing tool, to conduct our stress test. We executed the load test for 30 minutes with the below settings:

Number of Threads (Users) – 1000 (Number of users connects to the target).

1000 (Number of users connects to the target). Ramp-Up Period (in seconds) – The time frame for all requests to start. As per our configuration at every 0.01 second, 1 new thread will start i.e 100 threads/second.

The time frame for all requests to start. As per our configuration at every 0.01 second, 1 new thread will start i.e 100 threads/second. Loop Count – These 1000 threads perform a test iterations back-to-back.

These 1000 threads perform a test iterations back-to-back. Duration (seconds) – After ramp-up 1000 threads run continuously for 1800 seconds.

We were exercising the following scenarios in our load test:

Add a new pet owner to the system.

View information about a pet owner.

Add a new pet to a system.

View information about a pet.

Add information about a visit to a pet’s visitation history.

Update the information about a pet.

Update the information about a pet owner.

View owner information by searching his name.

View the information of all owners.

How to Measure Memory Wastage?

The industry has hundreds of tools to show the amount of memory used. But seldom we come across tools that can measure the amount of memory wasted due to inefficient programming. HeapHero is a simple tool that analyzes your heap dumps and tells how much memory is wasted due to inefficient programming.

We captured the heap dump from the Spring Boot Pet Clinic application when the test was running. (there are seven different options to capture heap dump from Java/Android applications. You can choose the option that is convenient for you).

We uploaded the captured heap dump into the HeapHero tool. Tool generated this beautiful report showing that 65% of memory is wasted due to inefficient programming. Yes, this is a simple vanilla application, which is supposed to have all the best practices implemented in it, that too on a highly celebrated framework is wasting 65% of memory.

Fig: Chart generated by HeapHero, showing 65% of memory is wasted by Spring Boot pet clinic application

Analyzing Memory Wastage

From the report you can notice the following:

15.6% of memory is wasted due to duplicate strings.

14.6% of memory is wasted due to inefficient primitive arrays.

14.3% of memory is wasted due to duplicate primitive arrays.

12.1% of memory is wasted due to inefficient collections.

Duplicate Strings

The top reason for memory wastage in this Spring boot application (and in most enterprise applications) is duplication of strings. The report shows how much memory is wasted due to duplicate of strings, what strings are they, who is creating them and how to optimize it.

Fig: Duplicate Strings

You can notice that 15.6% of memory is wasted due to duplicate strings. Please note

‘Goldi’ string is has been created 207,481 times.

‘Visit’ string has been created 132,308 times. ‘Visit’ was the description we mentioned in the test script.

‘Bangalore’ string has been created 75,374 times. ‘Banglore’ is the name of the city we specified in the test script.

‘123123123’ has been created 37,687 times.

‘Mahesh’ string has been created 37,687 times.

Apparently ‘Goldi’ is the name of the pet that was entered on the screen through the test script. ‘Visit’ was the description entered on the screen through the test script. Similarly, are the values. But the question why so many thousands of times these same string objects are created.

We all know that strings are immutable (i.e. once they are created, they can’t be modified). Given that why these many thousands of duplicate strings are created?

HeapHero tool also reports the code path where these duplicate strings are created.

Fig:Codepath from where duplicate strings are originating.

Here are the high-level recommendations to fix duplicate strings in your application. You can employ the strategies apply to your application.

Inefficient Collections

Another primary reason for memory wastage in the spring boot pet clinic application is inefficient collections implementation. Below is the excerpt from the HeapHero report:









































































Fig: Memory wasted due to inefficient collections

You can notice that 99% of LinkedHashSet in the memory doesn’t have any elements in them. If there are no elements, why even create LinkedHashSet? When you create a new LinkedHashSet object, space for 16 elements is reserved in memory. All the space reserved for those 16 elements is wasted now. If you do lazy initialization of the LinedHashset then this problem wouldn’t arise.

Bad Practice:

private LinkedHashSet<String, String>myHashSet = new LinkedHashSet(); public void addData(String key, String value) { myHashSet.put(key, value); }





Best Practice:

private LinkedHashSet<String, String>myHashSet; public void addData(String key, String value) { If (myHashSet == null) { myHashSet = new LinkedHashSet(); } myHashSet.put(key, value); }





Similarly, another observation is: 68% of ArrayList contains only 1 element in them. When you create an ArrayList object, space for 10 elements is reserved in memory. It means in 88% of ArrayList 9 elements space is wasted. If you can initialize ArrayList with capacity this problem can be avoided.

Bad Practice: Initializing Collections with default

new ArrayList();





Best Practice: Initialize Collections with capacity

new ArrayList(1);





Memory Is Not Cheap

One can counter-argue that memory is so cheap, so why do I need to worry about it? Fair question. But my friends’ memory is not cheap in the cloud computing era. There are 4 primary computing resources:

CPU. Memory. Network. Storage.

Your application might be running on tens, thousands of application servers running on AWS EC2 instances. In the above-mentioned four computing resources, which resource gets saturated in an EC2 instance? I request you to pause for a moment here, before reading further. Give thought to figure out which resource gets saturated first.

For most applications, it is *memory*. CPU is always at 30 – 60%. There is always an abundance of storage. It’s hard to saturate network (unless your application is streaming a lot of video content). Thus, for most applications, it’s the memory that is getting saturated first. Even though CPU, storage, network is underutilized, just because memory is getting saturated, you end up provisioning more and more EC2 instances. This will increase your computing cost by several folds.

On the other hand, without exception, modern applications waste anywhere from 30 – 90% of memory due to inefficient programming practices. Even above Spring boot pet clinic without much business logic is wasting 65% of memory. Real enterprise applications will be wasting in similar magnitude or even much more. Thus if you can write memory efficient code, it will bring down your computing cost.

As memory is the first resource to get saturated, if you can reduce memory consumption, you would be able to run your application on a smaller number of server instances. You might be able to reduce 30 – 40% of servers. It means your management can reduce 30 – 40% of the data center (or cloud hosting provider) cost, plus maintenance and support cost. It can account for several millions/billions of dollars in cost savings.

Conclusion

Besides reducing computing costs, your customer experience will also become a lot better when memory-efficient code is written. If you can reduce the number of objects that are created to service new incoming requests, your response time will get a lot better. Since fewer objects are created, fewer CPU cycles will be spent in creating and garbage collecting them. Reduction in response time will give a better customer experience.





Further Reading

A Disappointing Story on Java Memory Optimization

Duplicate Strings: How to Get Rid of Them and Save Memory

Detecting Memory Leaks From a JVM Heap Dump