Irwan Hendra's Random Codes Blog

 Spring Boot Reactive: Improving CPU bound performance using Scheduler In part 1 , we have seen that Spring Boot Reactive doesn't really improve performance if the WAITING time is CPU bound / CPU intensive tasks. This article show a quick way on how we can improve the speed through specific configuration Setup Spring Boot's embedded Tomcat is reconfigured to only use 10 worker threads, this way we can clearly see the performance limitation and tweaks. Gatling is configured to simulate 30 concurrent requests with 30000 milliseconds request timeout. APIs internal process is calling java native code that calculate the value of PI over 1 million iterations Default / No scheduler The main reason why CPU bound tasks do not improve (or even degrade) with high parallelism is because of the costly overhead for context switching in the low level. In the scenario below, 10 main threads are all being used to calculate PI values and because there are less CPU than threads, a lot of context

 Spring Boot 2: Using Spring WebFlux & Tomcat for Reactive APIs Spring WebFlux is a somewhat new (since 2019) library from Spring Boot 2 that provides massive improvement in performance compared to the traditional synchronous calls. To quote the Spring documentation itself: Why was Spring WebFlux created? Part of the answer is the need for a non-blocking web stack to handle concurrency with a small number of threads and scale with fewer hardware resources. Servlet 3.1 did provide an API for non-blocking I/O. However, using it leads away from the rest of the Servlet API, where contracts are synchronous ( Filter ,  Servlet ) or blocking ( getParameter ,  getPart ). This was the motivation for a new common API to serve as a foundation across any non-blocking runtime. That is important because of servers (such as Netty) that are well-established in the async, non-blocking space. Further reading:  https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html In s