3 ms·

One thing I would love to see is a Fiber-based job runner for mailers and other non-cpu-intensive jobs that spend most of their execution time waiting (say, doi

by WJW 5y ago

One thing I would love to see is a Fiber-based job runner for mailers and other non-cpu-intensive jobs that spend most of their execution time waiting (say, doing API calls). It seems like that would be one of the absolute sweet spots for the new Fiber scheduler stuff in Ruby 3.0. Preferably it'd be sidekiq compatible but you could have the fiber runner listening to one queue and the normal sidekiq runner(s) to another queue. I've been toying around with this idea for a while and the main blocker is the incompatibility of Rails (mostly AR) with some of the Fiber stuff. That is slowly getting cleared out though.

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 ago
  I 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)

by WJW 5y ago

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 ago
I 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)