# Backgroundrb alternative idea

**URL:** <https://www.ruby-forum.com/t/backgroundrb-alternative-idea/119720>\
**Category:** Rails\
**Created:** [November 9, 2007, 4:03pm UTC](https://www.ruby-forum.com/t/backgroundrb-alternative-idea/119720 "2007-11-09T16:03:19Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Reynard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/6bbea6/32.png) [@Reynard](https://www.ruby-forum.com/u/Reynard)\
**Post date:** [November 9, 2007, 4:03pm UTC](https://www.ruby-forum.com/t/backgroundrb-alternative-idea/119720/1 "2007-11-09T16:03:19Z")

</div>

I’m just wondering how many people are using backgroundrb on  
production site? and how’s the experience with backgroundrb?

> From my experience it’s been the cause of about 90% of our production  
> server problems: From results data corruption, backgroundrb server  
> hanging, worker process hanging and taking up memory.

So I was just thinking of an alternative solution.  
What if the worker is replaced with just a ruby script (can be  
anything actually: php, perl, etc)  
Rails application can just spawn new process by calling this worker  
script (passing data, and possibly uniq id)

The worker script then store the result in database keyed by the uniq  
id (which is accessible by the Rails app), So the Rails app can check  
on the result by querying the database.

Isn’t that a much better solution? Any comment / suggestion?

Regards,  
reynard

---

<div class="post-metadata">

**Author:** ![Reynard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/6bbea6/32.png) [@Reynard](https://www.ruby-forum.com/u/Reynard)\
**Post date:** [November 9, 2007, 4:41pm UTC](https://www.ruby-forum.com/t/backgroundrb-alternative-idea/119720/2 "2007-11-09T16:41:23Z")

</div>

On Nov 9, 2007, at 9:02 AM, Reynard wrote:

> I’m just wondering how many people are using backgroundrb on  
> production site? and how’s the experience with backgroundrb?
> 
> > From my experience it’s been the cause of about 90% of our production  
> > server problems: From results data corruption, backgroundrb server  
> > hanging, worker process hanging and taking up memory.

There is quite a bit of work going on with backgroundrb right now. I  
suggest you join the mailing list and catch up on the latest and  
greatest news. The maintainer has produced a rewrite that aims to  
cure the problems you describe. You may want to help him test it  
rather than create your own solution.

> Isn’t that a much better solution? Any comment / suggestion?

Sure, this could work. However, depending on the nature of the work  
it might create other performance problems for you. Spawning a whole  
new process, initializing the ruby (or other language) interpreter,  
loading libraries for database access, etc. is very heavy-weight  
particularly if the script doesn’t run for very long (a few seconds).  
This doesn’t scale very well.

Good luck.

---

<div class="post-metadata">

**Author:** ![Reynard](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/6bbea6/32.png) [@Reynard](https://www.ruby-forum.com/u/Reynard)\
**Post date:** [November 9, 2007, 5:01pm UTC](https://www.ruby-forum.com/t/backgroundrb-alternative-idea/119720/3 "2007-11-09T17:01:54Z")

</div>

Thanks for the suggestion, I just posted this idea on backgroundrb-devel  
list, and someone replied of having implemented similar solution. but  
yeah,  
there might be cases where backgroundrb will be a better solution for  
performance reason. I guess I’ll just have to try and test it to make  
sure  
the performance issue won’t be a problem.

- reynard

There is quite a bit of work going on with backgroundrb right now. I