# Script/runner and backgroundrb caching and performance

**URL:** <https://www.ruby-forum.com/t/script-runner-and-backgroundrb-caching-and-performance/172155>\
**Category:** Rails\
**Created:** [July 15, 2009, 6:41pm UTC](https://www.ruby-forum.com/t/script-runner-and-backgroundrb-caching-and-performance/172155 "2009-07-15T18:41:11Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jedrin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/47e85d/32.png) [@Jedrin](https://www.ruby-forum.com/u/Jedrin)\
**Post date:** [July 15, 2009, 6:41pm UTC](https://www.ruby-forum.com/t/script-runner-and-backgroundrb-caching-and-performance/172155/1 "2009-07-15T18:41:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Jedrin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/47e85d/32.png) [@Jedrin](https://www.ruby-forum.com/u/Jedrin)\
**Post date:** [July 15, 2009, 7:09pm UTC](https://www.ruby-forum.com/t/script-runner-and-backgroundrb-caching-and-performance/172155/2 "2009-07-15T19:09:15Z")

</div>

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.