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 productionserver 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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.> > 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. Good luck. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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> 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. > > 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. >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---