Backgroundrb devel - Aug 2009 - Question about backgroundrb and resource usage

On Aug 10, 2009, at 3:44 PM, Peter Gengler wrote:
> So I have a somewhat general question about backgroundrb and  
> resource usage.  I hadn?t really considered the fact that it spools  
> up a new rails process for each worker until I started making more  
> workers; now that I?m have half a dozen it seems like the current  
> design is really unscalable.  I.e. if my rails stack takes 200MB of  
> memory for example, that means 10 workers use 2GB of memory?  That  
> seems overly excessive to me, am I missing something that prevents  
> that resource bloat?
As far as I have seen, you''re not missing anything. I had the same  
problem and ended up having a single worker, with different methods  
for the work. I''m considering getting rid of backgroundrb altogether,  
favoring instead simply loading ActiveRecord and the model classes I  
need, with the hope that a cron task can fire the thing up within a  
few seconds. We need tasks to run every minute, so it must be fast  
loading. Anyway, that would allow us to unload a couple hundred meg at  
Engine Yard.

   adam

You know that''s an interesting point about the single worker; has
anyone ever used Skynet?  Their fortay is distributing map/reduce problems in
the background, but they also mixed in a function to ActiveRecord called
send_later which allowed you to send off any method of a model for later
processing.  I wrote my own mixin that does the same thing with Backgroundrb and
a GenericWorker class (and I added send_now_or_later so I could have a fallback)
because I liked keeping the functions on the model.  That would lend itself to
reducing the backgroundrb overhead as you''d have a single worker for
any asynchronous AR processing, although it doesn''t help with the
cron-style jobs.

\Peter

-----Original Message-----
From: Adam Williams [mailto:adam at thewilliams.ws] 
Sent: Monday, August 10, 2009 6:50 PM
To: Peter Gengler
Cc: backgroundrb-devel at rubyforge.org
Subject: Re: [Backgroundrb-devel] Question about backgroundrb and resource usage

On Aug 10, 2009, at 3:44 PM, Peter Gengler wrote:
> So I have a somewhat general question about backgroundrb and  
> resource usage.  I hadn''t really considered the fact that it
spools
> up a new rails process for each worker until I started making more  
> workers; now that I''m have half a dozen it seems like the current
> design is really unscalable.  I.e. if my rails stack takes 200MB of  
> memory for example, that means 10 workers use 2GB of memory?  That  
> seems overly excessive to me, am I missing something that prevents  
> that resource bloat?
As far as I have seen, you''re not missing anything. I had the same  
problem and ended up having a single worker, with different methods  
for the work. I''m considering getting rid of backgroundrb altogether,  
favoring instead simply loading ActiveRecord and the model classes I  
need, with the hope that a cron task can fire the thing up within a  
few seconds. We need tasks to run every minute, so it must be fast  
loading. Anyway, that would allow us to unload a couple hundred meg at  
Engine Yard.

   adam

It totally depends on what you are doing. If your task is thread-safe
you can even use thread_pool.defer() which will make sure that at
least IO sensitive tasks are running concurrently.

You don''t need 10 workers there. One worker with some thread pool
thrown around should suffice.



On Tue, Aug 11, 2009 at 5:47 AM, Peter Gengler<ppgengler at prevailhs.com>
wrote:
> You know that''s an interesting point about the single worker; has
anyone ever used Skynet? ?Their fortay is distributing map/reduce problems in
the background, but they also mixed in a function to ActiveRecord called
send_later which allowed you to send off any method of a model for later
processing. ?I wrote my own mixin that does the same thing with Backgroundrb and
a GenericWorker class (and I added send_now_or_later so I could have a fallback)
because I liked keeping the functions on the model. ?That would lend itself to
reducing the backgroundrb overhead as you''d have a single worker for
any asynchronous AR processing, although it doesn''t help with the
cron-style jobs.
>
> \Peter
>
> -----Original Message-----
> From: Adam Williams [mailto:adam at thewilliams.ws]
> Sent: Monday, August 10, 2009 6:50 PM
> To: Peter Gengler
> Cc: backgroundrb-devel at rubyforge.org
> Subject: Re: [Backgroundrb-devel] Question about backgroundrb and resource
usage
>
> On Aug 10, 2009, at 3:44 PM, Peter Gengler wrote:
>
>> So I have a somewhat general question about backgroundrb and
>> resource usage. ?I hadn''t really considered the fact that it
spools
>> up a new rails process for each worker until I started making more
>> workers; now that I''m have half a dozen it seems like the
current
>> design is really unscalable. ?I.e. if my rails stack takes 200MB of
>> memory for example, that means 10 workers use 2GB of memory? ?That
>> seems overly excessive to me, am I missing something that prevents
>> that resource bloat?
>
> As far as I have seen, you''re not missing anything. I had the same
> problem and ended up having a single worker, with different methods
> for the work. I''m considering getting rid of backgroundrb
altogether,
> favoring instead simply loading ActiveRecord and the model classes I
> need, with the hope that a cron task can fire the thing up within a
> few seconds. We need tasks to run every minute, so it must be fast
> loading. Anyway, that would allow us to unload a couple hundred meg at
> Engine Yard.
>
> ? adam
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>


-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org