31–40 of 115 posts
Mike is an inspiration to me and my project!
This is one of the best businesses I have heard of. Even 6-7 years back, Sidekiq was grossing $80k/month [1]. I imagine it must be much more now. No servers to maintain, no employees, minimal support work and Mike has the complete freedom to work on updates whenever he prefers. Almost entire revenue minus payment processing costs must be profit. Imagine making $1M / yr working only 10-20hrs per week (Don't wish to pr…
> I wonder what makes Sidekiq special? Time, know-how, and long term dedication are the key ingredients from my perspective. Maybe he's working 10-20 hours now, but there's support and development every day for the past 11 years. > I don't imagine any equivalent product (background job processing) in the other languages is raking in that much, if making any revenue in the first place. I guarantee, there are backgroun…
"I toyed with Sidekiq.js but decided to kill that idea real quick because, as we all know, JavaScript is terrible" This is why I love the ruby community, so much sense :)
From the JS community, this is sadly the level of snark we expect. It doesn't have to be like this. Your community tried to be better once. Have you forgotten? https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ma...
OK, maybe it's only, say, 96% of Ruby users, or 100% of Rails users at least
Earlier quoted context omitted.
When we used Sidekiq in production, not only did I never see crashes that lost us jobs, but there are also ways to protect yourself from that. I highly recommend writing your jobs to be idempotent.
Idempotence doesn't solve this problem. The jobs are all idempotent. The problem is that jobs will never be retried if a crash occurs. This doesn't happen at a high rate, but it happens more than zero times per week for us. We pay for Sidekiq Pro and have superfetch enabled so we are protected. If we didn't do so we'd need to create some additional infra to detect jobs that were never properly run and re-run them.
It’s hard to get this right though. No matter where the line gets drawn, free users will complain that they don’t get everything for free.
"I toyed with Sidekiq.js but decided to kill that idea real quick because, as we all know, JavaScript is terrible" This is why I love the ruby community, so much sense :)
From the JS community, this is sadly the level of snark we expect. It doesn't have to be like this. Your community tried to be better once. Have you forgotten? https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ma...
Regardless, it's probably better if we leave room for little jokes with each other.
I've been using sidekiq now for almost a decade and had the pleasure to meet Mike at a Ruby conf many years ago.
Earlier quoted context omitted.
I have no problem paying for the Pro version, but one if its marketing pitches is "enhanced reliability", which is a wild marketing spin on "the free version will lose jobs in fairly common scenarios". In sidekiq without super_fetch (a paid feature), any jobs in progress when a worker crashes are lost forever. If a worker merely encounters an exception the job will be put back on the queue and retried but a crash mea…
how often do your workers crash? i rely heavily on sidekiq and don't think I see this very often, if ever.
OOM kills are particularly pernicious as they can get into a vicious cycle of retry-killed-retry loops. The individual job causing the OOM isn't that important (we will identify it, log it and noop it), it's the blast radius effect on other sidekiq threads (we use up to 20 threads on some of our workers), so you want to be able to recover and re-run any jobs that are innocent victims of a misbehaving job.
"I toyed with Sidekiq.js but decided to kill that idea real quick because, as we all know, JavaScript is terrible" This is why I love the ruby community, so much sense :)
From the JS community, this is sadly the level of snark we expect. It doesn't have to be like this. Your community tried to be better once. Have you forgotten? https://jasonfleetwoodboldt.com/courses/stepping-up-rails/ma...