Tips for Choosing the Right Embedded Server for Your Spring Application: Tomcat, Jetty, or Undertow?

1. Understanding Embedded Servers in Spring

Embedded servers are a core part of modern Spring applications, allowing developers to bundle the server within the application itself. This offers flexibility, ease of deployment, and consistency across environments. The three most commonly used embedded servers with Spring Boot are Tomcat, Jetty, and Undertow, each having its unique strengths and weaknesses.

1.1 What is an Embedded Server?

An embedded server is a server instance that runs within your Spring Boot application as a dependency, rather than being deployed externally. It simplifies the deployment process by packaging everything into a single runnable JAR or WAR file.

For example, you can define an embedded server in your pom.xml file as follows:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId> <!-- or jetty/undertow -->
</dependency>

1.2 Why the Choice Matters?

The embedded server you choose can affect several aspects of your application, including startup time, memory usage, and handling of concurrent requests. Each server has different characteristics that might make it more or less suitable depending on your application’s requirements.

2. Comparing Tomcat, Jetty, and Undertow

To make an informed decision, it’s essential to understand how Tomcat, Jetty, and Undertow differ in terms of performance, feature set, and use cases. Below is a breakdown of each server’s strengths and where they might be most effective.

2.1 Apache Tomcat

Overview : Tomcat is the default embedded server in Spring Boot and is widely used due to its robust ecosystem, extensive documentation, and compatibility with a wide range of applications.

Performance : Tomcat is optimized for handling a large number of short-lived HTTP requests, making it a strong choice for traditional web applications.

Configuration Example : To configure Tomcat in Spring Boot, no additional setup is needed as it is the default option. However, you can fine-tune it by adding custom configurations in the application.properties file:

server.tomcat.max-threads=200
server.tomcat.uri-encoding=UTF-8

Use Cases:

• Suitable for most traditional web applications.
• Ideal for applications requiring extensive session management.

Demo Code and Results:

@RestController
public class TomcatController {

    @GetMapping("/tomcat-demo")
    public String tomcatDemo() {
        return "Running on Apache Tomcat!";
    }
}

Running this Spring Boot application will launch an embedded Tomcat server, accessible via http://localhost:8080/tomcat-demo , returning the response "Running on Apache Tomcat!".

2.2 Jetty

Overview : Jetty is known for its lightweight nature and scalability. It is highly customizable and often favored in environments where performance and resource efficiency are paramount.

Performance : Jetty excels in environments requiring high throughput and where memory footprint is a concern. It is also highly regarded for its support of asynchronous request processing.

Configuration Example : To switch to Jetty, you can exclude Tomcat and include Jetty in your pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

Use Cases:

• Best suited for applications requiring high concurrency and non-blocking I/O. Because Jetty is built on a highly efficient asynchronous I/O model. It uses Java’s java.nio (New I/O) package, which provides the ability to perform non-blocking operations on channels and selectors. This allows Jetty to manage thousands of simultaneous connections without creating a thread for each connection, reducing the overhead typically associated with traditional blocking I/O models.
• Ideal for microservices architectures due to its low memory usage. Jetty uses a highly optimized thread pool to manage concurrent requests. Instead of creating a new thread for each connection, Jetty reuses threads from a pool, reducing the cost of thread creation and destruction. This is crucial for handling high levels of concurrency because it allows Jetty to scale efficiently as the number of simultaneous connections grows. Jetty’s thread pool is also configurable, allowing developers to fine-tune the server’s behavior based on the specific needs of their application. This flexibility is another reason why Jetty is often chosen for applications where performance under high concurrency is a priority.

Demo Code and Results:

@RestController
public class JettyController {

    @GetMapping("/jetty-demo")
    public String jettyDemo() {
        return "Running on Jetty!";
    }
}

Launching this Spring Boot application will start Jetty as the embedded server, and accessing http://localhost:8080/jetty-demo will return "Running on Jetty!".

2.3 Undertow

Overview: Undertow is a newer option among the three and is designed for maximum performance, particularly in high-concurrency scenarios. It’s known for its low overhead and excellent support for non-blocking I/O.

Performance: Undertow can handle large volumes of concurrent requests with minimal resource consumption, making it a top choice for reactive applications.

Configuration Example : Switching to Undertow involves excluding Tomcat and adding Undertow in your pom.xml :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

Undertow is a lightweight and highly performant web server that is well-suited for microservices and high-performance applications, especially those requiring non-blocking I/O and cloud-native environments. Here’s why Undertow excels in these use cases:

Undertow is built with a non-blocking I/O model at its core. It uses Java’s java.nio (New I/O) framework, which allows it to handle multiple connections efficiently without dedicating a thread to each one. This means Undertow can process a large number of concurrent requests with minimal resource usage.

For example, in traditional blocking I/O servers, each connection might require its own thread, leading to high memory and CPU consumption when handling many simultaneous connections. In contrast, Undertow’s non-blocking model can manage thousands of connections with far fewer threads, reducing overhead and improving performance.

This non-blocking architecture is particularly advantageous for microservices, which often need to handle high levels of concurrency while maintaining low latency. Undertow’s ability to process requests asynchronously ensures that microservices remain responsive even under heavy load.

Why Undertow is Ideal for Microservices?

Microservices architectures typically involve deploying multiple small, independent services that communicate with each other over the network. These services must be lightweight, scalable, and able to handle high levels of concurrency without consuming excessive resources.

Undertow is an ideal fit for microservices because of its:

• Low Memory Footprint : Undertow is designed to be extremely lightweight, using minimal memory and CPU resources. This makes it perfect for deploying multiple instances in a microservices architecture where resource efficiency is crucial.
• Modular Design : Undertow’s modular architecture allows developers to include only the components they need, further reducing the resource footprint. This modularity also makes it easy to configure Undertow to meet the specific needs of each microservice.
• High Throughput : Undertow’s non-blocking I/O model and efficient request processing ensure high throughput, which is essential for microservices that need to handle many requests per second.

Undertow is optimized for high-speed request processing, making it an excellent choice for applications where performance is a critical factor. Its non-blocking architecture allows it to handle requests quickly and efficiently, minimizing latency and ensuring fast response times.

For instance, in a high-traffic web application, Undertow can handle a large number of incoming requests simultaneously without slowing down. This ability to maintain high performance under load is crucial for applications that need to provide a responsive user experience.

Demo Code and Results:

@RestController
public class UndertowController {

    @GetMapping("/undertow-demo")
    public String undertowDemo() {
        return "Running on Undertow!";
    }
}

This application will use Undertow as the embedded server, accessible via http://localhost:8080/undertow-demo , which will return "Running on Undertow!".

3. How to Choose the Right Embedded Server

Choosing between Tomcat, Jetty, and Undertow depends on your application’s specific needs, including the expected traffic, deployment environment, and resource constraints.

3.1 Performance Considerations

If your application needs to handle a large number of concurrent users with minimal resource usage, Undertow is likely the best choice. On the other hand, if your application is a standard web app with moderate traffic, Tomcat provides a balanced solution with extensive community support.

3.2 Customization and Flexibility

Jetty offers unparalleled customization options, which can be crucial in environments where you need fine-grained control over server behavior. For applications requiring asynchronous request processing, Jetty also stands out as the most efficient option.

3.3 Deployment Scenarios

For cloud-native or microservices architectures, Undertow’s lightweight and performant design make it ideal. However, for enterprises looking for a stable, tried-and-true solution with ample documentation and community resources, Tomcat remains a safe and reliable choice.

4. Conclusion

Selecting the right embedded server for your Spring application is not a one-size-fits-all decision. By understanding the strengths and weaknesses of Tomcat, Jetty, and Undertow, you can make a choice that aligns with your application’s performance needs, customization requirements, and deployment environment.

If you have any questions or need further clarification on choosing the right embedded server, feel free to comment below!

Read posts more at : Tips for Choosing the Right Embedded Server for Your Spring Application: Tomcat, Jetty, or Undertow?