Improving Microservices Performance with Spring WebFlux: Understanding publishOn vs subscribeOn

|

In the world of microservices, performance optimization is a critical aspect that determines the scalability and efficiency of distributed systems. Traditional blocking web frameworks, such as Spring MVC, can limit system throughput, especially when handling high volumes of concurrent requests. Enter Spring WebFlux, a non-blocking, reactive framework designed to solve performance bottlenecks by leveraging the reactive programming model. However, effective use of WebFlux requires understanding some core concepts, such as Schedulers, and more importantly, the differences between publishOn and subscribeOn in managing thread execution. In this article, we will dive deep into the concepts of publishOn and subscribeOn, explore their practical applications, and understand how these methods can be utilized to improve the performance of microservices built with Spring WebFlux.

Reactive Programming and WebFlux

Before we get into the specifics of publishOn and subscribeOn, it’s essential to understand what reactive programming is and how Spring WebFlux fits into the picture.

What is Reactive Programming?

Reactive programming is a declarative programming paradigm that focuses on data streams and the propagation of changes. It allows developers to build responsive, resilient, and scalable applications by leveraging asynchronous, non-blocking I/O operations.

In reactive systems, tasks are not executed sequentially but rather asynchronously. Each task gets a signal when the data it is dependent upon becomes available. This is different from the traditional blocking I/O where threads would be blocked while waiting for data.

Spring WebFlux

Spring WebFlux is a fully non-blocking, reactive web framework that works seamlessly with reactive libraries such as Project Reactor and RxJava. It offers high scalability and throughput by allowing developers to handle thousands of concurrent connections with a small number of threads. WebFlux works in tandem with the reactive model by embracing the Publisher–Subscriber relationship.

In a typical reactive flow, publishers emit data, and subscribers consume it. The threading model used to manage how these tasks are executed is crucial for performance. This is where publishOn and subscribeOn come into play.

The Role of Schedulers in WebFlux

In reactive programming, Schedulers represent different thread pools that determine on which thread a piece of work will run. In Reactor, the default scheduler is often the event loop, but developers can define custom schedulers for more control over the threading model.

There are three main types of schedulers commonly used in Reactor:

  1. Immediate: Executes the task on the current thread.
  2. Parallel: Optimized for parallel execution and CPU-bound tasks.
  3. Elastic: Suitable for blocking I/O tasks, such as interacting with a database or external service.

The Difference Between subscribeOn and publishOn

Both publishOn and subscribeOn are methods provided by Project Reactor to shift the execution context (threads) of a reactive stream. Understanding how they work is key to optimizing the performance of your WebFlux application.

subscribeOn

The subscribeOn operator is used to control the thread in which the subscription happens. It influences the entire subscription chain, meaning it affects not only the moment of subscription but also all upstream operators (the data emission part).

When you use subscribeOn, you’re telling the application which thread should handle the creation and subscription to the reactive stream. It is typically applied when a task requires a specific thread for the subscription logic.

Using subscribeOn

java
Flux<String> dataStream = Flux.just("Apple", "Banana", "Cherry")
.map(item -> {
System.out.println("Mapping on thread: " + Thread.currentThread().getName());
return item.toUpperCase();
})
.subscribeOn(Schedulers.parallel());dataStream.subscribe(item ->
System.out.println(“Consumed on thread: “ + Thread.currentThread().getName()));

Output

arduino
Mapping on thread: parallel-1
Consumed on thread: parallel-1

In this example, the subscribeOn(Schedulers.parallel()) call ensures that the entire stream’s subscription and mapping logic is executed on a thread from the parallel scheduler.

publishOn

In contrast, publishOn only influences the downstream execution of a reactive stream. The operators downstream from publishOn will be executed on the specified scheduler. publishOn is used when you want to switch the execution context at a specific point in the reactive pipeline, without affecting the upstream logic.

Using publishOn

java
Flux<String> dataStream = Flux.just("Apple", "Banana", "Cherry")
.map(item -> {
System.out.println("Mapping on thread: " + Thread.currentThread().getName());
return item.toUpperCase();
})
.publishOn(Schedulers.boundedElastic()) // Switch to boundedElastic scheduler
.map(item -> {
System.out.println("Processing on thread: " + Thread.currentThread().getName());
return "Fruit: " + item;
});dataStream.subscribe(item ->
System.out.println(“Consumed on thread: “ + Thread.currentThread().getName()));

Output

arduino
Mapping on thread: main
Processing on thread: boundedElastic-1
Consumed on thread: boundedElastic-1

In this example, publishOn switches the thread context after the first map operation. The mapping logic happens on the main thread, but the processing and consumption occur on a thread from the boundedElastic scheduler.

Practical Usage of publishOn and subscribeOn in WebFlux

Now that we have a clear understanding of publishOn and subscribeOn, let’s explore some practical scenarios where these operators can be utilized to optimize the performance of a Spring WebFlux-based microservice.

Using subscribeOn for Blocking I/O Operations

In many microservices, blocking I/O operations such as database access or API calls can become performance bottlenecks. By using subscribeOn, you can offload these operations to an elastic scheduler designed for blocking tasks, improving the responsiveness of the system.

java
@GetMapping("/products")
public Mono<Product> getProduct() {
return productService.getProduct()
.subscribeOn(Schedulers.boundedElastic()); // Offload to elastic scheduler
}

In this case, the getProduct method will execute the blocking database call on an elastic thread pool, preventing the event loop threads from getting blocked.

Switching Contexts with publishOn for CPU-Intensive Tasks

If a certain part of your application requires CPU-bound tasks, such as data processing or transformations, you can use publishOn to move the CPU-intensive work to a parallel scheduler.

java
@GetMapping("/processData")
public Mono<String> processData() {
return dataService.fetchData()
.map(data -> data.toLowerCase())
.publishOn(Schedulers.parallel()) // Move to parallel scheduler for CPU-bound work
.map(data -> complexDataTransformation(data));
}

Here, the data fetching happens on the event loop thread, but the complex transformation logic is moved to the parallel scheduler to take advantage of multiple CPU cores, improving the throughput for heavy workloads.

Combining subscribeOn and publishOn

Sometimes, you might need to use both subscribeOn and publishOn to control different aspects of a reactive flow. For example, you can offload blocking I/O to an elastic scheduler while performing CPU-bound tasks on a parallel scheduler.

java
@GetMapping("/optimize")
public Mono<String> optimizeTask() {
return taskService.performBlockingTask()
.subscribeOn(Schedulers.boundedElastic()) // Offload blocking task
.map(result -> complexCalculation(result))
.publishOn(Schedulers.parallel()) // Move CPU-bound task
.map(result -> finalizeProcessing(result));
}

This approach ensures that both blocking and CPU-intensive tasks are executed on optimal thread pools, significantly improving performance under heavy load.

Conclusion

Understanding the differences between publishOn and subscribeOn is crucial for optimizing the performance of microservices built with Spring WebFlux. While both operators are used to shift execution contexts, their applications vary significantly:

  • subscribeOn influences the entire subscription chain and is typically used for controlling the execution of upstream tasks like I/O operations.
  • publishOn only affects the downstream part of a reactive flow and is suitable for fine-grained control over specific parts of the reactive pipeline.

By strategically using publishOn and subscribeOn to manage thread pools and control the flow of tasks, developers can significantly enhance the scalability and performance of WebFlux-based microservices. When building reactive microservices, carefully analyzing your application’s workload (whether it’s CPU-intensive or I/O-bound) and applying these operators accordingly will lead to better resource utilization and improved system throughput.