Analyzing the performance impact of reactive relational database connection drivers on reactive Java applications

Abstract

This work analyzes the performance impact of a non-blocking Oracle database connection driver within a non-blocking or reactive microservices application context. To determine the importance of having a fully reactive system, a comparison between a reactive driver, in this case Oracle R2DBC, and JDBC is made through a shared Spring Boot application. This application performs an order invoicing service, which mixes local computations, simulations of I/O representing calls to external microservices, and SQL queries, allowing for multiple out-of-order executions in a single test. Additionally, the R2DBC and JDBC implementations of this service are tested with and without parallel execution. Results show similar average response times for both drivers when handling lighter workloads and higher resource usage by R2DBC, but considerably longer response times when using JDBC with heavier workloads. Reactive configurations mostly outperform their blocking counterparts, but non-parallel R2DBC notably underperforms JDBC with parallel execution after a certain threshold. This study’s findings emphasize the importance of total reactivity in applications using reactive APIs, given that processed data streams are sufficiently expressive and parallelism is leveraged when applicable.

Este trabalho analisa o impacto do uso de uma conexão não-bloqueante a uma base de dados Oracle no contexto de uma aplicação de microserviços reativa. Para determinar a importância de um sistema totalmente reativo, são comparados um driver reativo, neste caso Oracle R2DBC, e o driver bloqueante JDBC, ambos compartilhando uma mesma aplicação Spring Boot. Essa aplicação executa uma operação de "invoicing"de compras, que mescla computações locais, simulações de I/O representando chamadas a microserviços externos e consultas SQL, possibilitando múltiplas execuções fora de ordem em um mesmo teste. Complementarmente, as implementações desse serviço com R2DBC e JDBC são testadas com e sem execução paralela. Resultados mostram médias de tempo de resposta semelhantes em cenários de baixa carga de trabalho, mas consideravelmente maiores utilizando JDBC com cargas maiores. As configurações reativas majoritariamente superam suas equivalentes bloqueantes. Nota-se, porém, que a configuração de R2DBC não-paralela tem resultados piores em relação ao JDBC com paralelismo a partir de um dado ponto. As conclusões deste estudo evidenciam a importância da reatividade total em aplicações compostas por componentes reativos, dado que os volumes de dados por elas processados sejam suficientemente expressivos e, quando aplicável, processamento paralelo seja utilizado.