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
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.
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.
There is quite a bit of work going on with backgroundrb right now. I