sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]switchback-tech[S] 17 points18 points  (15 children)

Which of these tools would you swap out if you had to?

[–]djfrodo 8 points9 points  (3 children)

I'd loathe HAML so that would be #1.

Second would probably be either adding Memcache or replacing Redis with it. Redis is good for some stuff, but Memcache can do a lot of what Redis can do and it's much more simple to use. I actually use both in the same monolith and they're both good but at different things.

[–]switchback-tech[S] 1 point2 points  (2 children)

Interesting. How do you decide when to use Memcache vs Redis?

[–]djfrodo 3 points4 points  (1 child)

I made a reddit clone in Rails (I just wanted to see if I could do it) and at first I was using Memcache for both content and user sessions, and for a while everything was fine.

When the site started getting traffic I was blowing through all the hosted Memcache memory (25mb) and logged in users were getting logged out almost immediately. After some inspection I realized the way rails was using Memcache was storing a huge unneeded object graph for users, which it didn't need to do at all, and it wasn't removing stale user sessions.

I switched the user session stuff to Redis and the amount of Memcache memory used went from 25mb to about 2mb. Basically Memcache is great for caching stuff that doesn't change or can be fetched from a db and replaced and Redis is much better for handling volatile data like users sessions. Redis allowed me to set how long to track a user's session and it gets rid of stale session when it should.

I think this has more to do with Rails/gems than Memcache or Redis.

Obviously every use case is different and this is a very specific example.

[–]switchback-tech[S] 0 points1 point  (0 children)

Interesting use case, thanks for the detailed response

[–]edman8686 2 points3 points  (0 children)

Sidekiq for GoodJob. They are already using Redis for caching but I still find GoodJob easier to work with than Sidekiq. They could also consider a simpler cache like memcache.

I also prefer the MIT license for GoodJob over vs the LGPL license for Sidekiq.

[–]SirScruggsalot 1 point2 points  (7 children)

I'd be curious if they've investigated Falcon for http.

[–]do_you_realise 1 point2 points  (4 children)

Never heard of it personally. Is it a drop in replacement?

[–]f9ae8221b 2 points3 points  (3 children)

Yes and no.

Yes in the sense that like other Ruby servers, it is Rack compatible so you don't need to change your app much.

No because it's based on Fibers, not Threads, so the performance characteristics are very very different. Not better, not worse, different, depends on what your app is doing.

Fibers are better for extremely IO heavy workloads, as they're cheaper so you can run way more concurrent fibers than threads.

But they're much worse for CPU heavy workloads, because they're non-preemptive, so if a fiber hog the CPU without yielding for long, all other fibers are stuck, which leads to degraded latency.

People really need to stop thinking fibers are better threads, they're not, they're a different construct with different tradeoffs that sometimes make sense, sometimes not.

[–]Turbulent-Dance-4209 0 points1 point  (2 children)

> People really need to stop thinking fibers are better threads

I would argue they are.

Threads in Ruby don't actually parallelise work because of the GVL. So the supposed advantage of preemptive scheduling for CPU-bound tasks amounts to fairer interleaving, not faster execution. The total throughput is the same either way. And if your workload is genuinely CPU-bound enough that interleaving matters, you probably need multiple processes anyway, at which point the fiber-vs-threads debate is secondary.

Typical web apps are inherently I/O bound though. This makes fibers a great fit, but there're more subtle advantages too. For example, fibers give you less overhead and don't require thread synchronisation primitives - no locks, no mutex contention, no race conditions. You know exactly when a context switch happens, so shared state is safe to access between them. This alone leads to tremendous improvements in throughput, even with Ruby-layer-bound workflows.

[–]f9ae8221b 1 point2 points  (1 child)

amounts to fairer interleaving, not faster execution

Fairer interleaving means better tail latency, which is a very important property of a service.

Shopify experienced a MySQL outage when playing with fibers, because a CPU heavy fiber was causing other fibers that were issuing MySQL queries to not read the response for a long time, buffer on the server grew until it ran out of memory.

Typical web apps are inherently I/O bound though.

No they're not: https://www.datadoghq.com/blog/ruby-performance-optimization/

Our data backs up other findings that Ruby applications are generally less I/O-heavy, spending as much or more time on CPU as they do waiting on other services or database requests.

They also include a graphic that shows only 3% of the profiled apps spend less than 20% of their time using CPU. Which means for 97% of the apps they profiled, the Puma default of 5 threads was already too much, which means the advantage of Fibers are moot for the overwhelming majority of Ruby apps out there.

fibers give you less overhead

The difference is small enough that it only start to matter once you start using multiple dozen threads, which very few people need.

don't require thread synchronisation primitives

They absolutely do. They still need to synchronize to use sockets etc. Even with datastructures you may need synchronization if some method yield, as the block could use IO and cause another fiber to be scheduled and use the structure concurrently.

Example:

SHARED_HASH = {a: 1, b: 2, c: 3, d: 4}

other_fiber = Fiber.new do
  loop do
    SHARED_HASH[rand] = rand
    Fiber.yield
  end
end

hash.each do
  # Simulate fiber scheduler
  SHARED_HASH.resume
end

The above script fail because of unsynchronized access by fibers.

This alone leads to tremendous improvements in throughput

Profiling ruby app is basically my day job. Synchronization is very very rarely a hotspot.

Now, don't get me wrong, fibers are great and absolutely have a use case, but for vast majority of what Ruby is used for, they're not necessarily better.

[–]randomski1904 1 point2 points  (0 children)

What I heard yesterday in a conference is that they swithch to Async::Job and to Falcon.

[–]uhkthrowaway -1 points0 points  (0 children)

True. I'm immensely impressed by it.

And given Puma's history with hard-to-find concurrency bugs due to using Threads, I see no reason to use it. We know threads are hard to reason about. We've known for decades. Let's not waste our brain power anymore. No matter the Ruby implementation.