Solid Queue 1.6.0 now supports fiber workers
1–10 of 41 posts
Re: Solid Queue 1.6.0 now supports fiber workers
#2This is a nice update.
Is it possible to either have multiple ractors dispatching jobs with fibres or to set up multiple queues with different strategies?
E.g. one for IO bound and one for CPU bound?
With Sidekiq I’ve had luck having workers running on Truffleruby but generally don’t use it for my main rails apps.
Re: Solid Queue 1.6.0 now supports fiber workers
#3So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
Re: Solid Queue 1.6.0 now supports fiber workers
#4So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
Some programmers find it easier to write concurrent programs that use "light-weight threads", "fibers", "goroutines", "coroutines" or other variants of this idea.
This feature is obviously intended for them and it might enhance their productivity.
Nonetheless, no program that uses a great number of any variant of the "light-weight threads" can ever be as efficient as a thread pool that is dimensioned to have the same number of threads as the number of hardware threads of a SMT CPU, or a slightly greater number of threads than the number of hardware threads of a non-SMT CPU.
For maximum performance, the use of a correctly-sized thread pool remains the best solution, but writing an efficient program that uses it can be significantly more difficult, because good methods of communication and synchronization must be implemented, while the run-time library of a language with "light-weight threads"/"fibers"/etc. already takes care of such problems so the programmer does not need to think about them.
Re: Solid Queue 1.6.0 now supports fiber workers
#5My concern is number of database connections. In the example it's 100 fibers per worker, at that rate you are going to exhaust db connections sooner. Happy to be wrong.
Re: Solid Queue 1.6.0 now supports fiber workers
#6My concern is number of database connections. In the example it's 100 fibers per worker, at that rate you are going to exhaust db connections sooner. Happy to be wrong.
I don't know Solid Queue or the rails environment, but I expect that not every worker will create it's own connection, there should be a connection pool in-between
Re: Solid Queue 1.6.0 now supports fiber workers
#7My concern is number of database connections. In the example it's 100 fibers per worker, at that rate you are going to exhaust db connections sooner. Happy to be wrong.
I think you want to make sure you don't hold a database connection while waiting on other slow async work (like outgoing HTTP requests). Then you can more feasibly have more workers than pool size. It's just very tricky to do this in Rails...
Re: Solid Queue 1.6.0 now supports fiber workers
#8So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
It’s more like goroutines or other lightweight concurrency mechanisms. If threads are OS-level concurrency primitives, fibers are scheduled within Ruby itself, which makes them much more efficient than threads.
In fact, I got the following results in HTTP benchmark tests:
Go:
* Latency under stable load: p95 0.25–5.32 ms, p99 2.20–9.92 ms * Memory: 23–31 MB RSS across HTTP scenarios
Ruby:
* Latency under stable load: p95 1.03–6.45 ms, p99 2.32–8.30 ms * Memory: 84–295 MB RSS, depending on the scenario
Fibers can also handle WebSockets better because WebSocket workloads involve more I/O waiting.
A typical Falcon setup uses N workers, one thread per worker, and many fibers. Since the fibers are cooperatively scheduled within a single thread, this avoids much of the context-switching overhead associated with OS threads. Multiple workers can still run in parallel across CPU cores.
Re: Solid Queue 1.6.0 now supports fiber workers
#9My concern is number of database connections. In the example it's 100 fibers per worker, at that rate you are going to exhaust db connections sooner. Happy to be wrong.
I don't know Solid Queue or the rails environment, but I expect that not every worker will create it's own connection, there should be a connection pool in-between
I think by default they check out a new connection when obtained a job and then release it. In comparison with some async languages like JS where a connection is only checked when a query is about to be executed
Re: Solid Queue 1.6.0 now supports fiber workers
#10So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
It’s more like goroutines or other lightweight concurrency mechanisms. If threads are OS-level concurrency primitives, fibers are scheduled within Ruby itself, which makes them much more efficient than threads. In fact, I got the following results in HTTP benchmark tests: Go: * Latency under stable load: p95 0.25–5.32 ms, p99 2.20–9.92 ms * Memory: 23–31 MB RSS across HTTP scenarios Ruby: * Latency under stable load:…
To dig a bit into why fibers are more efficient than threads.
The OS has a rather opaque view on what happens in a thread. It doesn't know how the memory is used or what memory is efficient. The OS can block a thread when it runs into IO, but it doesn't know or care about what other threads in an application it can or should activate.
Fibers bring the threading into the application layer. While the application can't choose which and when a thread runs, it can make choices about which fibers to run. Further, the application knows intimate details about things like the stack of a given thread. When it goes to park a fiber, it knows just how much memory should be saved off so the fiber can resume and it doesn't have to save off all the memory allocated to a thread's stack. Further, because so many programs are stack based an application can pretty smartly save and reuse segments of the stack which are common amongst fibers. So, for example, if you spin off 1000 fibers at one location in code, the stack for those 1000 fibers will be identical right up until the fiber starts executing.
The main drawback of fibers is they can't implement things like fair scheduling. Applications have few ways to park a currently running fiber to let another one run if, for example, the app wants to make some progress on all the fibers alive. The app has to wait for the fiber to hit some sort of IO point in the code or insert explicit park checks (The JVM actually does this for GC purposes. It creates "safepoints" which application threads make a quick check to see if the JVM wants to start a GC). The OS has more power here, it can simply interrupt the thread and start running something else for a given quanta.