6 ms·

Rescuing Resque: Let's do this

140 points by craigkerstiens 14y ago

alrs 14y ago
It may read as tangential, but this feels like the beginning of end of "forget free software, let's get Macs."
- w1ntermute 14y ago
  Someone needs to start a similar project with Ubuntu. Things are clearly getting a bit desperate for them (or so it seems) . If a good number of quality developers finds a good arrangement whereby they can donate a few hours of their time every week to significantly improving it, some real changes could be created. There are definitely a lot of people who are not happy with the way that Apple has been acting as of late. What if we were to select one (1) laptop model and work on making Ubuntu on it a seamless experience?
  - shardling 14y ago
    I don't think there's any actual indication that Ubuntu is in trouble. Sure there is grumbling on the internet when they change UI, but that's pretty par for the course.
    - w1ntermute 14y ago
      I was referring to the addition of advertising to the OS, not the move to Unity.
      - desas 14y ago
        There is 100% hardware compatibility on many laptops already, I'm not sure that that is the problem. Canonical need to be more profitable, indeed they're probably not or barely profitable yet. They seem to have two ways of increasing profit a) monetising their existing desktop user base and b) Getting more desktop users so that more businesses become comfortable with it and buy business support.
        w1ntermute 14y ago
        > There is 100% hardware compatibility on many laptops already, I'm not sure that that is the problem. Then what is the problem exactly? Every time Ubuntu comes up, people ask if it is fully hardware compatible. Is that just a branding issue, where people think Ubuntu isn't hardware compatible with most modern laptops?
        desas 14y ago
        Hardware compatibility is a problem, having a group of people all targeting one particular laptop to fix is worthwhile but isn't a great way to fix it. There are various laptops that can be pointed to if you're persuading someone buying a new laptop to install ubuntu (though which is poorly documented). There are multiple problems, the main one is that windows is known, comes "free" and already installed when you buy a computer, is less of a risk and is good enough. Most people will know a "computer guy" who can help them with windows or be comfortable that they can pay someone otherwise. Software is a bigger problem in some ways than hardware now (though the web is fixing this), note the effort Ubuntu are putting into the software centre, allowing paid for apps, proposing to relax the restrictions to get new software into Ubuntu, running app competitions and so forth. Selling operating systems isn't easy, look at how long apple have toiled in the wilderness and they have linked hardware, loads of good will via ipod/iphone, billions in the bank and have managed to climb to something like 5%-10% market share.
      - shardling 14y ago
        I am unclear on why you think that is an indication of desperation. In contrast, Mozilla gets most of its income in an almost identical way (making google a default search provider) and that's not considered desperate.
  - alrs 14y ago
    The best way to improve Ubuntu is to get involved with Debian. That's where the heavy lifting is.
    - w1ntermute 14y ago
      Well, wherever the help is needed. My point is that if we can get a large number of skilled developers involved in improving the code behind Ubuntu through a small weekly commitment, that could really solve a lot of the existing issues.
    - emillon 14y ago
      This. I started to get involved in Debian a few years ago (though I'm a long-time user) and this is really really interesting work. There are a lot of packages with too little workforce where you can go through a list of dozens or hundreds of bugs. alrs is true ; in most cases your work is automatically replicated to Ubuntu (where the package-maintainer relationship is less strong than in Debian. Most packages don't have a dedicated maintainer there). And everyone can do it ; no sign-up or complicated process required. You just have to find a sponsor for your packages which is just a fancy name for "every code needs review". Debian is often described as bureaucratic but most of the processes are very sane.
pimeys 14y ago
Resque isn't so great after all. We used it with around 600-1000 jobs per minute and not without problems. The failure backends could be better. We need the retry backend and for that you have to install another gem. The retry feature was kind of not working so well and really hard to debug (thanks to EventMachine and Resque's a bit too complicated failure backend). Our solution was to build yet another queueing and worker system. For queues Beanstalkd is way faster and way more reliable than Redis. Instead of EventMachine I built the workers with Ruby threads and making a retry system on top of it wasn't really a problem. Our error percentage dropped from around 10% to 0.0001% on average. Maybe some day I might release this as a gem, if world really needs yet another queueing system.
- robotmay 14y ago
  Wow, someone else using Beanstalkd; my hero! Beanstalkd may be one of my favourite but most neglected pieces of software.
  - pimeys 14y ago
    It is a blast. Although we had our concerns because you can't see what's inside a Beanstalkd queue (duh, because it's a queue), but building a system for monitoring the failures was not a big deal. And of course the tubes rock. Now I can build a separate tube for each retry, I can set different priorities for the tubes (so the more fail prone tubes won't block all workers), I can set a deadline for a job to finish and if the worker dies in the middle the job will be returned for the other workers. And best of all, I can monitor all tubes nicely with Graphite.
    - fullmoon 14y ago
      Why do you feel that a queue is inherently unpeekable?
      - pimeys 14y ago
        You can peek, but it's not built for looking through all the items in it. It is doable, but not very efficient.
robotmay 14y ago
I switched from Resque to Mike Perham's Sidekiq earlier in the year, and the improvement is just sensational. I'm curious to see how Resque can be improved to bring it up to the same level.
- lucaspiller 14y ago
  ++ on Sidekiq. We've been using it since April and have had no issues at all. From the readme: "Sidekiq is compatible with Resque. It uses the exact same message format as Resque so it can integrate into an existing Resque processing farm. You can have Sidekiq and Resque run side-by-side at the same time and use the Resque client to enqueue messages in Redis to be processed by Sidekiq. At the same time, Sidekiq uses multithreading so it is much more memory efficient than Resque (which forks a new process for every job). You'll find that you might need 50 200MB resque processes to peg your CPU whereas one 300MB Sidekiq process will peg the same CPU and perform the same amount of work. Please see my blog post on Resque's memory efficiency and how I was able to shrink a Carbon Five client's resque processing farm from 9 machines to 1 machine."
- Axsuul 14y ago
  This, especially if you're doing any crawling or network-bottlenecked task. Those extra workers that you can fit within your memory footprint is money.
mytrile 14y ago
We've already migrated to Sidekiq which seems much better and supported MQ.
deleted 14y ago
[deleted]
mrzor 14y ago
Hello everyone ! We recently released jobco, a simple Resque distribution. You can check it out at https://github.com/mrzor/jobco https://github.com/mrzor/jobco We attempted to address some of the issues we had with our resque 1.x stack regarding productivity (ease to use both in development, and ease to deploy) and regarding API consistency (rewrote resque-status to keep the Resque API intact). It doesn't address any of the high throughput issues that were mentioned earlier. I'm definitely up to help fixing stuff within Resque when appropriate. However, the Jobco project is possibly more appropriate if the feature you're looking after can be provided using plugins, or involves providing better CLI interface to Resque. You can find out my email address using `git log` on the jobco repo.
khangtoh 14y ago
Resque should just be left alone and let it retire. SideKiq is the present and future.
- mrzor 14y ago
  Sometimes the forking model have desirable properties. Numerous past articles covered this in one way or another. Choosing between SideKiq and Resque is primarily a matter of choosing between forked processes and threads. Retiring Resque and let SideKiq be the present and the future would destroy that choice. SideKiq, as a threaded impl., can claim some cool benefits : - shorter job launch times (only interesting if you actually run thousands of second spanning jobs a minute) - reduced memory footprint (you probably have little to no amount of thread local storage) I will venture that the reduced memory footprint is mostly the result of the unfriendly to copy-on-write GC we have to live with using 1.9. Resque has a clean and simple API and a decent ecosystem. It can and hopefully will evolve into something cooler and more powerful - even if worthy alternatives exist.
100k 14y ago
I didn't realize GitHub had abandoned Resque. What are they using now? Or is it in "works for me" status and they don't feel like changing it?
cypherpunks01 14y ago
This post convinced me to re-think using Resque in a new webapp of mine. I'm thinking about Celery + RabbitMQ now, does anyone have feedback about this or other recommendations? (i'm in a python wsgi stack)
- pjscott 14y ago
  Celery is very slick and low-effort, and should fit in nicely with the rest of your Python code base. Go for it!

140 points by craigkerstiens 14y ago

alrs 14y ago

It may read as tangential, but this feels like the beginning of end of "forget free software, let's get Macs."

w1ntermute 14y ago
Someone needs to start a similar project with Ubuntu. Things are clearly getting a bit desperate for them (or so it seems) . If a good number of quality developers finds a good arrangement whereby they can donate a few hours of their time every week to significantly improving it, some real changes could be created. There are definitely a lot of people who are not happy with the way that Apple has been acting as of late. What if we were to select one (1) laptop model and work on making Ubuntu on it a seamless experience?
- shardling 14y ago
  I don't think there's any actual indication that Ubuntu is in trouble. Sure there is grumbling on the internet when they change UI, but that's pretty par for the course.
  - w1ntermute 14y ago
    I was referring to the addition of advertising to the OS, not the move to Unity.
    - desas 14y ago
      There is 100% hardware compatibility on many laptops already, I'm not sure that that is the problem. Canonical need to be more profitable, indeed they're probably not or barely profitable yet. They seem to have two ways of increasing profit a) monetising their existing desktop user base and b) Getting more desktop users so that more businesses become comfortable with it and buy business support.
      - w1ntermute 14y ago
        > There is 100% hardware compatibility on many laptops already, I'm not sure that that is the problem. Then what is the problem exactly? Every time Ubuntu comes up, people ask if it is fully hardware compatible. Is that just a branding issue, where people think Ubuntu isn't hardware compatible with most modern laptops?
        desas 14y ago
        Hardware compatibility is a problem, having a group of people all targeting one particular laptop to fix is worthwhile but isn't a great way to fix it. There are various laptops that can be pointed to if you're persuading someone buying a new laptop to install ubuntu (though which is poorly documented). There are multiple problems, the main one is that windows is known, comes "free" and already installed when you buy a computer, is less of a risk and is good enough. Most people will know a "computer guy" who can help them with windows or be comfortable that they can pay someone otherwise. Software is a bigger problem in some ways than hardware now (though the web is fixing this), note the effort Ubuntu are putting into the software centre, allowing paid for apps, proposing to relax the restrictions to get new software into Ubuntu, running app competitions and so forth. Selling operating systems isn't easy, look at how long apple have toiled in the wilderness and they have linked hardware, loads of good will via ipod/iphone, billions in the bank and have managed to climb to something like 5%-10% market share.
    - shardling 14y ago
      I am unclear on why you think that is an indication of desperation. In contrast, Mozilla gets most of its income in an almost identical way (making google a default search provider) and that's not considered desperate.
- alrs 14y ago
  The best way to improve Ubuntu is to get involved with Debian. That's where the heavy lifting is.
  - w1ntermute 14y ago
    Well, wherever the help is needed. My point is that if we can get a large number of skilled developers involved in improving the code behind Ubuntu through a small weekly commitment, that could really solve a lot of the existing issues.
  - emillon 14y ago
    This. I started to get involved in Debian a few years ago (though I'm a long-time user) and this is really really interesting work. There are a lot of packages with too little workforce where you can go through a list of dozens or hundreds of bugs. alrs is true ; in most cases your work is automatically replicated to Ubuntu (where the package-maintainer relationship is less strong than in Debian. Most packages don't have a dedicated maintainer there). And everyone can do it ; no sign-up or complicated process required. You just have to find a sponsor for your packages which is just a fancy name for "every code needs review". Debian is often described as bureaucratic but most of the processes are very sane.

pimeys 14y ago

Resque isn't so great after all. We used it with around 600-1000 jobs per minute and not without problems. The failure backends could be better. We need the retry backend and for that you have to install another gem. The retry feature was kind of not working so well and really hard to debug (thanks to EventMachine and Resque's a bit too complicated failure backend). Our solution was to build yet another queueing and worker system. For queues Beanstalkd is way faster and way more reliable than Redis. Instead of EventMachine I built the workers with Ruby threads and making a retry system on top of it wasn't really a problem. Our error percentage dropped from around 10% to 0.0001% on average. Maybe some day I might release this as a gem, if world really needs yet another queueing system.

robotmay 14y ago
Wow, someone else using Beanstalkd; my hero! Beanstalkd may be one of my favourite but most neglected pieces of software.
- pimeys 14y ago
  It is a blast. Although we had our concerns because you can't see what's inside a Beanstalkd queue (duh, because it's a queue), but building a system for monitoring the failures was not a big deal. And of course the tubes rock. Now I can build a separate tube for each retry, I can set different priorities for the tubes (so the more fail prone tubes won't block all workers), I can set a deadline for a job to finish and if the worker dies in the middle the job will be returned for the other workers. And best of all, I can monitor all tubes nicely with Graphite.
  - fullmoon 14y ago
    Why do you feel that a queue is inherently unpeekable?
    - pimeys 14y ago
      You can peek, but it's not built for looking through all the items in it. It is doable, but not very efficient.

robotmay 14y ago

I switched from Resque to Mike Perham's Sidekiq earlier in the year, and the improvement is just sensational. I'm curious to see how Resque can be improved to bring it up to the same level.

lucaspiller 14y ago
++ on Sidekiq. We've been using it since April and have had no issues at all. From the readme: "Sidekiq is compatible with Resque. It uses the exact same message format as Resque so it can integrate into an existing Resque processing farm. You can have Sidekiq and Resque run side-by-side at the same time and use the Resque client to enqueue messages in Redis to be processed by Sidekiq. At the same time, Sidekiq uses multithreading so it is much more memory efficient than Resque (which forks a new process for every job). You'll find that you might need 50 200MB resque processes to peg your CPU whereas one 300MB Sidekiq process will peg the same CPU and perform the same amount of work. Please see my blog post on Resque's memory efficiency and how I was able to shrink a Carbon Five client's resque processing farm from 9 machines to 1 machine."
Axsuul 14y ago
This, especially if you're doing any crawling or network-bottlenecked task. Those extra workers that you can fit within your memory footprint is money.

mytrile 14y ago

We've already migrated to Sidekiq which seems much better and supported MQ.

deleted 14y ago

[deleted]

mrzor 14y ago

Hello everyone ! We recently released jobco, a simple Resque distribution. You can check it out at https://github.com/mrzor/jobco https://github.com/mrzor/jobco We attempted to address some of the issues we had with our resque 1.x stack regarding productivity (ease to use both in development, and ease to deploy) and regarding API consistency (rewrote resque-status to keep the Resque API intact). It doesn't address any of the high throughput issues that were mentioned earlier. I'm definitely up to help fixing stuff within Resque when appropriate. However, the Jobco project is possibly more appropriate if the feature you're looking after can be provided using plugins, or involves providing better CLI interface to Resque. You can find out my email address using `git log` on the jobco repo.

khangtoh 14y ago

Resque should just be left alone and let it retire. SideKiq is the present and future.

mrzor 14y ago
Sometimes the forking model have desirable properties. Numerous past articles covered this in one way or another. Choosing between SideKiq and Resque is primarily a matter of choosing between forked processes and threads. Retiring Resque and let SideKiq be the present and the future would destroy that choice. SideKiq, as a threaded impl., can claim some cool benefits : - shorter job launch times (only interesting if you actually run thousands of second spanning jobs a minute) - reduced memory footprint (you probably have little to no amount of thread local storage) I will venture that the reduced memory footprint is mostly the result of the unfriendly to copy-on-write GC we have to live with using 1.9. Resque has a clean and simple API and a decent ecosystem. It can and hopefully will evolve into something cooler and more powerful - even if worthy alternatives exist.

100k 14y ago

I didn't realize GitHub had abandoned Resque. What are they using now? Or is it in "works for me" status and they don't feel like changing it?

cypherpunks01 14y ago

This post convinced me to re-think using Resque in a new webapp of mine. I'm thinking about Celery + RabbitMQ now, does anyone have feedback about this or other recommendations? (i'm in a python wsgi stack)

pjscott 14y ago
Celery is very slick and low-effort, and should fit in nicely with the rest of your Python code base. Go for it!