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?
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.
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?
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.
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.