Script/runner and backgroundrb caching and performance

Rails
1

I have a few questions.

One is that it seems like script/runner does some caching because if
you destroy a bunch of active record models using myrec.destroy, then
if you do a find() of some sort, they are still there (even though you
deleted them) until the instance of script runner that you are in
exits. Then if you restart it, the find will not find it.

Based on that, it seems that it might be better to have a long
running process spawn script/runner jobs separately rather than have a
script/runner that runs for a long time and does a ton of stuff, not
sure on that ?

I also noticed that backgroundrb logs to the same log as the web
server. If a whole ton of stuff happens in backgroundrb, could this
potentially slow down the web server because it uses the same log
file ? The same question applies for script/runner. I see it happening
more so because I run the server from the console while developing
probably etc.

2

Hello–

On Jul 15, 2009, at 9:40 AM, Jedrin wrote:

Based on that, it seems that it might be better to have a long
running process spawn script/runner jobs separately rather than have a
script/runner that runs for a long time and does a ton of stuff, not
sure on that ?

I also noticed that backgroundrb logs to the same log as the web
server. If a whole ton of stuff happens in backgroundrb, could this
potentially slow down the web server because it uses the same log
file ? The same question applies for script/runner. I see it happening
more so because I run the server from the console while developing
probably etc.

You might try

YourARModel.clear_query_cache

if you feel caching is to blame for returning stale (already deleted)
rows. However, I am skeptical that caching is the problem, as it
(AFAICT) caches the most recent query so you have to make a query
identical to the last one for it to kick in. Additionally, any
modification to the model such as creating, updating, or deleting
should invalidate that cache.

You might try to reproduce this in a simple test case and look at the
SQL in your logs to make sure you are seeing what you expect.