Use case for limiting the number of fibers generated.

[jphager2]

I have a rack application that I am porting from puma. In the application, a middleware creates a database connection and sets it to Thread.current.

Under load, falcon's unlimited use of fibers seems to cause database connection limit errors. Normally with puma, you can calculate how many database connections you will need by workers * threads.

It may be interesting to allow falcon to limit the number of fibers generated so that these resource limitations can be managed.

[trevorturk]

I ran into a similar issue when I tested rails/rails#44219 it overloaded my database with connections. I'm not sure where the "fix" for this should be, since in my case I'm thinking of Active Record, but in yours it's a custom middleware. I'm curious if you got anywhere with this in any case, since it's on my mind, too!

[ioquatix]

IMHO, one option is to put a semaphore around resources that have known limits. We could introduce a semaphore with a timeout, which might solve this more generally. I know AR already has a timeout around database connections. However, apparently they are going to stop holding onto a connection for the duration of the request. This should reduce the pressure quite a bit.

[trevorturk]

Oh, that's an interesting idea -- a semaphore could work well for this kind of case, if I only want 5 concurrent db connections or something like that. I'm tempted to suggest adding docs to Rails about this re Rails' new isolation_level feature, because that really jumped out at me, although I wasn't using pgBouncer, so really it was my fault.

Do you have a reference for the AR connection change idea? I think I remember seeing something like that but couldn't remember where. There was chatter in rails/rails#44219 and rails/rails#45994 but I don't think that's what you mean.

[ioquatix]

@matthewd might have more information about it.

[matthewd]

I think rails/rails#42271 (comment) is about the most concrete I've gotten on it so far. Still fairly aspirational at this point, but it would have pgBouncer-ish benefits even for threaded servers, so it definitely seems like a place I'd like to end up.

[j-manu]

@ioquatix With #219 being merged, it's very likely that more users will run into connection pool limits. Please consider a config option for limiting concurrency.