# Disabling static file lookups?

**URL:** <https://www.ruby-forum.com/t/disabling-static-file-lookups/155461>\
**Category:** Mongrel\
**Created:** [December 12, 2008, 3:06am UTC](https://www.ruby-forum.com/t/disabling-static-file-lookups/155461 "2008-12-12T03:06:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Cody\_Caughlan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@Cody\_Caughlan](https://www.ruby-forum.com/u/Cody_Caughlan)\
**Post date:** [December 12, 2008, 3:06am UTC](https://www.ruby-forum.com/t/disabling-static-file-lookups/155461/1 "2008-12-12T03:06:06Z")

</div>

In looking at a running mongrel process in strace and at the code  
itself Mongrel will always look for a file under “public” (with and  
without a .html extension). When those filesystem lookups fail, it  
then passes the request to Rails.

So my question is, would you get more performance by disabling this  
lookup and just handing it off to Rails from the get go?

I understand that in development, the current behavior is desired as  
Mongrel is acting as the primary HTTP server. But in production, with  
a HTTP server like Apache or nginx in front and configured to serve  
static files, then it might make sense to not have Mongrel concern  
itself with looking for static files.

Maybe the OS caches those filesystem calls (stat cache?) and this  
would be a crazy premature optimization.

Thoughts?

/Cody

---

<div class="post-metadata">

**Author:** ![Cody\_Caughlan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@Cody\_Caughlan](https://www.ruby-forum.com/u/Cody_Caughlan)\
**Post date:** [December 12, 2008, 5:55pm UTC](https://www.ruby-forum.com/t/disabling-static-file-lookups/155461/2 "2008-12-12T17:55:46Z")

</div>

On Dec 11, 2008, at 6:05 PM, Cody Caughlan wrote:

> a HTTP server like Apache or nginx in front and configured to serve  
> static files, then it might make sense to not have Mongrel concern  
> itself with looking for static files.
> 
> Maybe the OS caches those filesystem calls (stat cache?) and this  
> would be a crazy premature optimization.
> 
> Thoughts?
> 
> /Cody

You should be able to alter the railshandler to not do these lookups  
when a config option is set. Merb uses rack middleware to do the  
static pages and that can be easily turned off in production. I  
believe latest rails does this as well and maybe you can disable these  
checks with rack in rails as well?

Cheers-

Ezra Z.  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![Cody\_Caughlan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@Cody\_Caughlan](https://www.ruby-forum.com/u/Cody_Caughlan)\
**Post date:** [December 12, 2008, 6:03pm UTC](https://www.ruby-forum.com/t/disabling-static-file-lookups/155461/3 "2008-12-12T18:03:24Z")

</div>

Ezra- thanks for your feedback.

My greater question is: is it worth it, in the long run? Or is it too  
negligible?

/Cody

---

<div class="post-metadata">

**Author:** ![Cody\_Caughlan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/dec6dc/32.png) [@Cody\_Caughlan](https://www.ruby-forum.com/u/Cody_Caughlan)\
**Post date:** [December 12, 2008, 6:11pm UTC](https://www.ruby-forum.com/t/disabling-static-file-lookups/155461/4 "2008-12-12T18:11:03Z")

</div>

On Dec 12, 2008, at 8:57 AM, Cody Caughlan wrote:

> Ezra- thanks for your feedback.
> 
> My greater question is: is it worth it, in the long run? Or is it too  
> negligible?
> 
> /Cody

Hmm i bet it is probably worth it but only if you are trying to  
squeeze every last drop of perf out of your setup. A fast local  
filesystem does stats fairly quick and I doubt you will be bale to  
tell the difference.

But if you have overtaxed disks or are using NFS or a shared  
filesystem of sorts then every littel bit helps to keep from touching  
the filesystem.

So its probably worth it eventually when you get big but probably is  
not worth it until you actually know it is a problem.

Cheers-

Ezra Z.  
removed\_email\_address@domain.invalid
