Clojurians Log v2

Please fix me if I'm wrong. I'm new to clojure & jdbc connection pooling(jdbc.pool.c3p0) Trying to understand the proper config. My DB gives me 20 connections, so I set jdbc.pool.c3p0/make-datasource-spec to :initial-pool-size 19 :min-pool-size 19 :max-pool-size 19 right? All 19 connections available from the pool + one more for remote access to production(single connection, not via pool)? Let's say only one person may want to access production repl at a time.

:min-pool-size
Minimum number of Connections a pool will maintain at any given time.

:max-pool-size
Maximum number of Connections a pool will maintain at any given time.

:initial-pool-size
Number of Connections a pool will try to acquire upon

I'm working on comparing databases with large loads (thousands of queries per second). The test code is written in Clojure, and uses next.jdbc for database access. Currently the code is single-threaded, and way too slow. As a result, I need to parallelize it. What would be the best option for parallelizing this code so that I can execute thousands of database queries per second? The code is deployed in GCP, so hardware resources are not the bottleneck. The main issue is that I'm not sure what is the best way to parallelize this type of I/O-bound workload. I have thought of a few solutions: 1. Built-in tools such as future/pmap , which would have sufficient functionality. However, they might be problematic due to the limited number of available threads (since I'm aiming for over 1000qps). 2. Some event-driven solution. However, I'm not sure if such a solution would improve performance because next.jdbc is sequential AFAIK. Maybe I should swap next.jdbc for some other tool entirely? I would greatly appreciate any directions or ideas on this problem, since I'm having a hard time understanding what type of solution would be the most suitable for this situation.

one alternative: https://github.com/metosin/porsas

@salo.kristian Unfortunately fibers aren't here yet, so maybe starting with some connection pooling might help a bit

but the ideal would be some connection pooling in addition to 1 fiber per request

you won't find any jdbc thing that isn't sequential

anything that claims to be is just throwing jdbc stuff on threads

(or using vendor/db specific extensions)

porsas does look promising, but it is unfortunately not suitable, since I need to work with several specialized databases such as InfluxDB and BigTable

@salo.kristian what about core.async and go channels?