[kotlin/vertx-web-kotlinx-exposed-r2dbc] Add 4 variant configurations to compare R2DBC connection pool strategies for vertx-web-kotlinx-exposed-r2dbc-postgresql#10722
Open
ShreckYe wants to merge 3 commits intoTechEmpower:masterfrom
Open
Conversation
…egies for vertx-web-kotlinx (exposed-r2dbc-postgresql and r2dbc-postgresql) (#16) * Initial plan * Optimize R2DBC connection pool configuration for vertx-web-kotlinx-exposed-r2dbc-postgresql - Replace generic ConnectionFactories.get() with optimized PostgresqlConnectionFactory - Add TCP optimizations: tcpKeepAlive(true), tcpNoDelay(true), sslMode(DISABLE) - Add connection pool timeouts: maxIdleTime(30s), maxAcquireTime(5s) - Add connection validation query: SELECT 1 - Increase pool size from 1 to 512 to match ktor-netty-exposed-r2dbc-dsl configuration Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Share R2dbcDatabase instance across verticles instead of creating per-verticle pools - Create single R2dbcDatabase with 512-connection pool in Main.kt - Pass shared instance to all MainVerticle instances via constructor - Eliminates N*512 connection pools (one per CPU core) problem - Now correctly uses a single shared pool of 512 connections total Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Add 4 benchmark configurations for R2DBC connection pool comparison - Config 1 (separate-pool-size-1): Original code with pool size 1 per verticle - Config 2 (separate-pool-size-8): Pool size 8 per verticle (~512 total on 56-core machine) - Config 3 (separate-pool-size-8-optimized): Config 2 with optimized connection settings - Config 4 (shared-pool-512-optimized): Shared pool of 512 with optimized settings Created: - MainVerticleSeparatePool.kt for per-verticle pool configurations - 4 Main*.kt entry points for each configuration - R2dbcOriginal.kt for original connection factory - 4 dockerfiles with appropriate entry points - Updated benchmark_config.json with all 4 configurations - Updated build.gradle.kts to generate start scripts for all configurations Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Refactor to use CLI arguments instead of multiple main functions - Removed separate Main*.kt files, use single Main.kt with CLI args - Merged MainVerticleSeparatePool into MainVerticle.kt as factory functions - Reverted build.gradle.kts to original state (no multiple start scripts needed) - Updated dockerfiles to pass CLI args: isSharedPool poolSize useOptimizedConfig - Renamed shared-pool-512-optimized to shared-pool-size-512-optimized for consistency - Removed backwards compatibility aliases from R2dbc.kt - Reverted original vertx-web-kotlinx-exposed-r2dbc-postgresql.dockerfile to original state Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Fix SSL certificate issues for TFB and Gradle builds - Added --trusted-host flags to pip install in main Dockerfile - Created init.gradle to allow insecure protocols in Gradle repositories - Updated buildSrc/build.gradle.kts to use explicit dependencies instead of version catalog - Updated buildSrc/settings.gradle.kts to configure repositories properly - Added GRADLE_OPTS environment variables to framework dockerfiles - Updated gradle.properties with SSL trust properties Changes enable tfb command to run without SSL certificate verification errors. Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Update dockerfile with CA certificates and permissions fixes - Added CA certificates update to fix SSL issues - Fixed permissions for gradle user - Simplified buildSrc/build.gradle.kts with explicit kotlin-dsl version - Added comprehensive SSL environment variables Progress: Main TFB Docker image builds successfully. Framework build still blocked by Gradle plugin repository SSL issues. Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Revert unsuccessful SSL workaround attempts - back to f0d386a Reverted commits 98683e8 and 9604e5d which attempted to fix SSL certificate issues but were unsuccessful in the GitHub Actions environment. Removed: - init.gradle (SSL workaround configuration) - gradle.properties (SSL trust properties) - CA certificate updates in dockerfiles - buildSrc modifications for SSL handling - Dockerfile pip SSL workarounds Back to working 4-configuration implementation with CLI arguments. Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Restore gradle.properties that existed at f0d386a The gradle.properties file with parallel and configuration-cache settings existed at f0d386a and should not have been deleted. Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Remove 2 unused functions * Rename * Rename and reorganize some functions * Rename for clarity Reviewed by Copilot. * Remove unused code which is also put in the wrong file * Replicate 4 benchmark configurations for vertx-web-kotlinx-r2dbc-postgresql - Updated r2dbc Main.kt to accept CLI arguments (isSharedPool, poolSize, useOptimizedConfig) - Updated r2dbc MainVerticle to accept ConnectionFactory parameter - Added MainVerticleWithSeparatePool factory function for separate pool configurations - Created 4 new dockerfiles for r2dbc-postgresql variants: * separate-pool-size-1: Pool size 1 per verticle, original connection factory * separate-pool-size-8: Pool size 8 per verticle (~512 total on 56-core), original factory * separate-pool-size-8-optimized: Pool size 8 with optimized TCP settings and validation * shared-pool-size-512-optimized: Single shared pool of 512 with optimizations - Added 4 new test configurations to benchmark_config.json - Build verification successful This mirrors the exposed-r2dbc-postgresql configuration approach for comprehensive comparison. Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> * Fix r2dbc Main.kt to properly handle separate pool mode - Removed unreachable throw statement - Restructured code to only create connectionFactory when isSharedPool is true - Separate pool mode now correctly calls MainVerticleWithSeparatePool factory function This fixes the GitHub Actions failure where the 3 r2dbc-postgresql separate pool configurations were not launching properly. Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: ShreckYe <27768951+ShreckYe@users.noreply.github.com> Co-authored-by: Yongshun Ye <ShreckYe@gmail.com>
Contributor
|
Please add the maintainers in the So with any change or marked as broken, it'll be notified to them. Example: |
Contributor
Author
|
Thanks! I understand the limit. These 4 benchmarks Otherwise, I could remove some benchmark portions unrelated to the connection pool comparison purpose in this PR temporarily, and add them back in the follow-up revert PR I mentioned. |
Contributor
|
I don't merge the PRs, @msmith-techempower will decide it. I understand that is really good to test better configurations and need to be a way to do it. |
Member
|
This really isn't how you should be testing configuration. I sympathize that it takes a long time to benchmark on our hardware (and thank you @joanhey in your pruning broken tests to speed that up), but allowing this many permutations will just add even more turnaround time. What I recommend is to try a configuration, wait for the benchmark, then open a new PR to test in the next run. |
ShreckYe
changed the title
vertx-web-kotlinx-exposed-r2dbc-postgresql and vertx-web-kotlinx-r2dbc-postgresqlvertx-web-kotlinx-exposed-r2dbc-postgresql
Contributor
Author
|
OK thanks. I have removed the |
ShreckYe
changed the title
vertx-web-kotlinx-exposed-r2dbc-postgresqlvertx-web-kotlinx-exposed-r2dbc-postgresql
ShreckYe
changed the title
vertx-web-kotlinx-exposed-r2dbc-postgresqlvertx-web-kotlinx-exposed-r2dbc-postgresql
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After #10560 was merged and its Continuous Benchmarking results came out, I noticed that some results appear to be significantly poorer relatively than what I got on my device. Specifically, the
vertx-web-kotlinx-exposed-r2dbc-postgresqlresults are poorer than those ofktor-netty-exposed-r2dbc-dsl, which is unusual because they share basically the same DB operation logic, while Vert.x is more performant than Ktor. I suspect its connection and pooling configurations are not optimal for your server.Since the results look fine on my device, I'd like to benchmark these different configurations on your server via Continuous Benchmarking to determine the optimal configuration. The code is mostly generated by Copilot as it's simple repetitive code and has been reviewed quickly by me. I will open a follow-up PR to revert these changes and apply the optimal configuration once the results are available. Thanks.