# Migrating from Developing Asynchronous Multi-Threading Programs to Reactive Programs in Java
## 7 Evaluation of Results
### Performance Analysis
#### 7.2.3 Discussion of Results  
The memory consumed on startup by reactive applications is about 35% less compared to the asynchronous ones, which would allow for faster scheduling inside a cluster, reducing \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Type** & **Description** & **Quantity** & **Purpose** \\ \hline \multirow{3}{*}{Unit Tests} & Tests focusing on individual & \multirow{3}{*}{\(\sim\)150 per service (1023 total)} & Ensures correctness and reliability of \\  & code components or methods. & & \\ \cline{1-1}  & & & smaller functional units of \\ \hline \multirow{3}{*}{Behavior-Driven Tests} & Feature-based Cucumber tests, & \multirow{3}{*}{50 scenarios} & Validates user-facing functionality, \\  & written in Gherkin to validate & & integration, and consistency between \\  & end-to-end behavior. & & asynchronous and reactive implementations. \\ \hline \multirow{3}{*}{Performance Tests} & Simulations of concurrent & \multirow{3}{*}{4 scenarios \(\times\) 7 concurrency} & Measures resource usage (CPU, \\  & users performing specific & & levels (10, 50, 100, 250, 500, \\ \cline{1-1}  & actions. & 750, 1000 users) & varying load conditions to compare \\ \cline{1-1}  & & & asynchronous and reactive \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Summary of application tests. Figure 8: Performance results for fetching user messages. deployment duration while also optimizing resource allocation and utilization inside orchestration platforms such as Kubernetes. The startup time for reactive microservices is approximately 35% lower than that of asynchronous variants, contributing to an optimal transition in the case of a rolling deployment strategy, minimizing downtime, and even preventing readiness errors when deploying several replicas, therefore ensuring continuity of service operations, which is important in distributed environments focused on maintaining high availability and reliability. The size of the resulting artifacts is also notably smaller for reactive applications, with a difference of about 30%, mainly due to the smaller number of dependencies required. The deployment of these smaller artifacts is inherently accelerated, simplifying the storage processes on various platforms and reducing the size and download times of container images, such as those used in Docker. In the first performance testing scenario, the reactive model demonstrated clear advantages over the asynchronous model, particularly at mid and high-concurrency levels, where its non-blocking architecture allowed it to handle increased load more efficiently. At a low concurrency level of 10 users, the reactive model reduced memory consumption by 6.25% (60 MB vs. 64 MB) and CPU usage by 11.9% (5.2% vs. 5.9%). Response times were also lower, with the average response time reduced by 12.5% (8 ms vs. 9 ms) and the 90 th percentile reduced by 18.2% (9 ms vs. 11 ms). Throughput was 8.4% higher (1015 req/s vs. 936 req/s), indicating that even under light loads, the reactive model achieved measurable efficiency gains, particularly in memory usage and response times. At a mid-concurrency level of 500 users, the reactive model showed significant advantages. Memory consumption was reduced by 22.4% (260 MB vs. 335 MB), and the average response time was 26.1% lower (51 ms vs. 69 ms). The 90 th percentile response time showed an even greater improvement, with the reactive model achieving 61 ms compared to 141 ms for the asynchronous model, a reduction of 56.7%. Throughput was 34.5% higher (8075 req/s vs. 6008 req/s). While CPU usage was slightly higher for the reactive model (37.3% vs. 34.2%), the overall gains in memory efficiency and response times outweighed this minor increase. These results highlight the scalability and responsiveness of the reactive approach at moderate concurrency levels. At the peak concurrency level of 1000 users, the reactive model demonstrated substantial advantages. Memory consumption was reduced by 12% (473 MB vs. 535 MB), and the average response time was 25.6% lower (93 ms vs. 125 ms).