Java, Programming, Struts2, jQuery, AngularJS and more > AWS > API Gateway > Serverless AWS Lambda performance of Apache Struts2 vs. Spring Boot

Serverless AWS Lambda performance of Apache Struts2 vs. Spring Boot

In the last time I was checking out spring boot for Serverless AWS Lambda microservices behind an AWS API Gateway Proxy as application pattern. While evaluating this, I was thinking if this pattern would be also possible with the Apache Struts2 web framework as well. So I was trying to reuse the same Struts2 application I created for my Angular with Struts2 REST plugin presentation a while ago. Because this application is quite simple and has just two controllers one for the multi language support and one to manage some dummy orders which are just stored in a static list.

There was some work necessary to transform this application in an AWS Lambda compatible application, but with some time it runs now like a charm. The result of my experiments are now available as a new Struts2 plugin for AWS cloud support. The git repository contains the plugin which makes it quite easy to run a Struts2 REST plugin based application as an AWS Lambda function. You just need to map the actions in an API Gateway and ready is your lambda based web app. The other part is a example lambda application with the order manager mentioned before.

After this plugin was released, I thought about a comparison between a similar Spring Boot lambda application and the created example application based on Struts. I think the results are quite interesting and I split the framework comparison in different sections.

1. Configuration

While Struts2 configuration for applications based on convention and REST plugin are in generally easy to configure and the start is quite fast, but against Spring Boot with the automatic generation and Java based configuration it loos this section.

Struts2 vs. Spring Boot: 0:1

2. Controller Configuration

In Struts2 I can code my controller actions without a lot of annotations while in Spring I need for each endpoint a separate Annotation. I like the convention based approach a lot but also the very flexible and easy action configuration of Spring is great. I think both ways of action developing are a good way so there is no clear winner in this section.

Struts2 vs. Spring Boot: 1:2

3. Package size

A microservice for lambda functions should be as small as possible. I used a plain Spring Boot application with Web configuration only for this test. For both applications I use the Maven Assembly Plugin to generate the final ZIP file. The final packed Spring application has a size of 16.1MB, while the Struts2 Example with some more resource files and additional language controller has a size of only 9.6MB. Clear winner here is Struts2.

Struts2 vs. Spring Boot: 2:2

4. Memory usage

You need to configure the expected memory usage for each lambda function, I used the default of 512MB for each lambda function. When testing the application in the AWS console the max memory used is printed out. Spring Boot was using 175MB and Struts2 only needed 123MB.

Struts2 vs. Spring Boot: 3:2

5. Performance

Last point of my comparison is the performance of both frameworks. To measure the performance I setup a simple Apache JMeter test case with HTTP request to the API Gateway endpoint with some threads and loops so in the end 360 GET and POST request are made to the endpoint. Here Spring Boot has an average response of 60-80ms while Struts2 has a response time of 70-85ms. There is no clear winner here for me, maybe Spring is a little little bit faster. But I would count this as a draw between both frameworks.

Response Time Graph Spring Boot

Response Time Graph Struts2

Struts2 vs. Spring Boot: 4:3

Conclusion

With a result of 4:3 Struts2 is a close winner in this comparison. I think both frameworks are a nice approach for this use case. When you plan to also use aother components from the Spring stack beside the Web part, I would favour Spring. But Struts2 could be an great option as well. Especially because of the small size and the low memory usage it is perfect for simple microservices in the AWS Lambda context.

What do you think? Did I miss something here?