Rails concurrency model is per process. So you will have `n_workers` pools and the amount of connections will be `n_workers * 3` based on the code you shared. The production machine has 28 total threads [1], which means Rails is starting 35 workers, according to their auto tuning code [2]. Overall, Rails uses 35x more pools than the Phoenix application and has twice the number of connections (105). It is absurd to imply that Rails is actually running with far less.
Second of all, the database pool needs to be 512 or 1024 if your app server can push traffic quickly enough to the database. If you are increasing the Rails pool size and it is not getting faster, then Rails is your bottleneck. Based on the runs I did last week, it seems the pool is the bottleneck in Elixir's case. We will know for sure in a couple weeks once the PRs land.
> If these people can't get good results in tuning Elixir, who can?
You can look at the results from the latest community efforts in main: https://www.techempower.com/benchmarks/#section=test&runid=1...
If you want to compare with Rails in particular, we beat Rails in every benchmark except two:
1. Single query: which will be tackled by better sizing our pools
2. Plain text: where we are currently sending the wrong payload (but when we sent the proper payload, as in the last published round, we beat Rails too)
And it does not include any of my proposed changes yet.
My point is exactly that the feedback cycle is long, so it takes time, and I was not able to invest time before. But given how intent some folks are to misinterpret benchmarks (and assign malice to the whole community), it is probably better to continue looking into it.
[1]: https://ark.intel.com/content/www/us/en/ark/products/120474/...
[2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...