2 ms·
I'd like to see it as well. However It's not immediately evident to me by how much this will improve things; afaik you will hit a bottleneck that is in the numb
by weatherlite 5y ago
I'd like to see it as well.
However It's not immediately evident to me by how much this will improve things; afaik you will hit a bottleneck that is in the number of available db connection (since each fiber, just like threads, has to borrow a db connection from the pool).
Fibers have a lot of potential but not in the one request per thread/fiber model we have now. Or perhaps I'm thinking about this wrong?
- WJW 5y agoI have in one of my applications a background job that basically does the following: - Some quick database lookups (~ 10 ms total) - An API call (depends on the time of day, but between 500-800 ms) - Another quick database insert (~ 20 ms usually) The job only needs a db connection for about 5% of the total runtime of the job and can give the connection back to the pool while the API call is running. Many mailer jobs in the system have a similar db-to-api-call ratio. (Also, I am of the opinion that all but the very biggest sites should not have any problems with db connections. Get a database that handles tons of connections gracefully like MySQL or use something like pgbouncer when using Postgres. Having low connection limits should not be a problem in 2022)