# 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 90 th percentile response time was significantly improved for the reactive model, reduced by 57.2% (294 ms vs. 688 ms). Throughput was 25.3% higher for the reactive model, with 3714 req/s compared to 2965 req/s for the asynchronous model. CPU usage was also slightly lower for the reactive model (26.9% vs. 28.7%), highlighting its efficiency under high-concurrency conditions. In the fourth scenario, the reactive model faced significant challenges and demonstrated limitations compared to the asynchronous model. This test involved large-scale data retrieval with substantial computational overhead, exposing potential inefficiencies in the reactive paradigm under specific conditions. At a low concurrency level of 10 users, the reactive model consumed slightly less memory than the asynchronous model, reducing memory usage by 6.5% (187 MB vs. 200 MB). However, CPU usage was significantly higher for the reactive model, more than doubling at 41.2% compared to 17.9% for the asynchronous model. Response times were considerably worse, with the average response time for the reactive model more than double that of the asynchronous model (113 ms vs. 47 ms). Throughput was also much lower, with the reactive model handling only 75 req/s, a 57.9% decrease compared to the asynchronous model's 178 req/s. At a mid-concurrency level of 250 users, the reactive model continued to consume significantly less memory, with a 61.3% reduction compared to the asynchronous model (324 MB vs. 837 MB). However, CPU usage for the reactive model was double that of the asynchronous model (68.8% vs. 34%). Average response times were substantially worse for the reactive model, with an increase of 152.2% (1991 ms vs. 789 ms). The 90 th percentile response time also reflected this inefficiency, with the reactive model reaching 2905 ms compared to 1434 ms for the asynchronous model. Throughput remained considerably lower for the reactive model, recording 104 req/s, a 60.5% reduction compared to the asynchronous model's 263 req/s. At the peak concurrency level of 1000 users, the reactive model consumed 65.1% less memory than the asynchronous model (691 MB vs. 1979 MB), showcasing its typical efficiency in memory management. However, CPU usage was 35.3% higher for the reactive model (80.9% vs. 59.8%). Average response times were more than double for the reactive model, reaching 8275 ms compared to 3755 ms for the asynchronous model, while the 90 th percentile response time increased to 10,547 ms for the reactive model, compared to 7195 ms for the asynchronous model. Throughput remained a significant limitation for the reactive model, achieving only 99 req/s, a 54.6% reduction compared to the asynchronous model's 218 req/s. To isolate the root cause of the performance limitation, the sequential steps in the code flow were isolated or swapped. Subsequently, JMeter tests were rerun after each modification to determine which of these altered steps resulted in metrics that were comparable to those of the asynchronous application. Initially, the mapping functions responsible for converting entities to DTOs were removed. Next, the Redis cache layer and the calls to the interaction service were excluded to determine if these contributed to the observed latency. Finally, it was concluded that the performance limitations are likely related to the database interactions. Monitoring during the tests indicated that the database reached its I/O limits, as evidenced by Docker metrics. This suggests that the limitations are primarily caused by database interactions, potentially influenced by the data access abstraction provided by Spring Data, the driver for PostgreSQL, or the constraints of the containerized database. Additional investigation is required to confirm these findings and to rule out other contributing factors, such as inefficiencies in the implementation or limitations in the testing methodology.