Rails: Use a connection pool for the database connection#177
Rails: Use a connection pool for the database connection#177p8 wants to merge 1 commit intoMDA2AV:mainfrom
Conversation
|
/benchmark |
|
🚀 Benchmark run triggered for |
|
Nice idea moving from thread-local connections to a proper connection pool — that's cleaner for managing DB access across Puma workers. One thing though: the Also worth considering: with Benchmark is running so we'll see if it makes a measurable difference! |
Benchmark ResultsFramework: Full log |
|
Benchmark results are in! Comparing against PR #175 baseline: Baseline/pipelined/json — essentially identical, which makes sense since those don't touch the DB. Mixed test (DB-heavy) — regression:
And notably, PR #177 is showing ~10.9% 5xx errors in the mixed test that weren't present in PR #175 (which had 0 5xx). That suggests the connection pool is actually causing failures under high concurrency — possibly pool exhaustion with The thread-local approach (one connection per Puma thread, no contention) might actually be the better fit for this workload. Connection pools shine when you have more threads than DB connections, but here SQLite is the bottleneck anyway. Might be worth bumping the pool size to match Puma's thread count and seeing if the 5xx errors go away, but honestly the previous approach was simpler and faster for this use case. |
BennyFranciscus
left a comment
There was a problem hiding this comment.
Straightforward improvement. ConnectionPool is standard Ruby practice for thread-safe DB access. Pool size 4 with timeout 5 is reasonable. Clean.
No description provided.