21–30 of 41 posts
As someone who spent 15+ years doing Ruby/Rails, it’s nice to see this land. That said, these days you’ll pry the BEAM from my cold, dead hands. It’s hard to go back to any other concurrency story.
Earlier quoted context omitted.
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:…
I'm unclear on the relevance of a comparison between Go and Ruby here. Ruby is radically slower than Go. It's down there with Python, if not a touch behind [1]. From the outside, I'd expect that it's possible that slight improvements in the context switching time will be dwarfed by the generally slow execution of Ruby itself; that is, if Ruby is going to take 100 microseconds to do something, whether it context switc…
So 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:…
Earlier quoted context omitted.
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
Has anyone played with this and SQLite? I have no data, just a hunch, but I’d think this is a recipe for corruption if you’re doing lots of writes.
As someone who spent 15+ years doing Ruby/Rails, it’s nice to see this land. That said, these days you’ll pry the BEAM from my cold, dead hands. It’s hard to go back to any other concurrency story.
Same path & agreed. The amount of things you do not have to care about with BEAM/Elixir compared to Rails is really interesting.
What could I stop caring about?
As someone who spent 15+ years doing Ruby/Rails, it’s nice to see this land. That said, these days you’ll pry the BEAM from my cold, dead hands. It’s hard to go back to any other concurrency story.
Same path & agreed. The amount of things you do not have to care about with BEAM/Elixir compared to Rails is really interesting.
Compared to Ruby. Elixir land doesn't have something similar to Rails, and phoenix is not it.
My 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.
Carmine (which coded this Fibers update) wrote about this in his blog. See the section 'The database connection math'. And no, you won't have one connection per fiber. The difference is staggering when you compare to threaded mode: it requires 1,320 database connections to run the same benchmark that the fiber mode runs with 60. https://paolino.me/solid-queue-doesnt-need-a-thread-per-job/
There is absolutely no logical reason why database pool sizing could be a reason for preferring fibers over threads.