Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm in the process of restructuring my project's web stack to: nginx -> haproxy -> many (apache/passenger rails) instances

Some of the goals include:

  • single location for page caching (currently done via rails on each apache machine)
  • faster static content
  • remove ssl from internal pipeline
  • ip logging (previously lost due to running haproxy in tcp mode)

The image/stylesheet/javascript assets are cache cached, with appropiate headers. Our page caching is based on internal parameters, and shouldn't respond to typical cache controls. To achieve these ends, our config looks something like

server {

    ...

    location /really_slow_dynamic_content/ {
        root /var/www/tmp;
        error_page 404 = @fetch;
    }

    location @fetch {
        internal;
        proxy_pass   haproxy_ip;
        proxy_store  /var/www/tmp${uri}_cache.html;
        proxy_store_access  user:rw  group:rw  all:r;
    }

    location /assets/ {
        proxy_pass   haproxy_ip;
        proxy_cache  assets;
    }

    location / {
        proxy_pass   haproxy_ip;
    }
}

I'm not really much of a sysadmin, and I know there are lots of alternatives/tweaks/additions that might be helpful. I also don't quite understand the different between proxy_cache and proxy_store. So to my actual question...

Until we move the assets to the nginx machine, does it make sense to use proxy_cache for assets and proxy_store for slow dynamic content?

Also, if there are other considerations or software I should be considering, I would love to hear about them. Thank you!


Since posting this question, I've realized that the initial config I used doesn't use the store at all, and that the error_page and internal settings from the (semi?) official wiki example weren't exactly optional (config updated here since it seems to be working, and a working config seems like a better legacy for this question). So, using the store for slow to create (and rarely updated) full pages, and the actual cache for images, javascript and such seems to be working pretty well for us. I'll accept the one answer, since it at least gave me a lead to track down my issue, but I still don't have a sense of whether or not I'm using the two directives in a manner for which they were intended or not (well, at least not regarding the store, the cache seems a bit more obvious).

share|improve this question
    
For legacy purposes, this discussion was very helpful for me when dealing with these issues. ruby-forum.com/topic/140396 –  Ckhrysze Jan 5 '11 at 17:24
add comment

2 Answers

up vote 1 down vote accepted

If memory serves me correctly, proxy_store stores a binary representation of a request for an item whereas proxy_cache stores a cached copy of the item in it's base form.

proxy_cache is actually a proper caching engine with multiple levels and is suitable for storing content from multiple sites using the same keys.

I personally use proxy_cache to store over 2 billion product images on each of our static content servers.

share|improve this answer
add comment

proxy_store is used to create an 'on demand' mirror of objects. It puts items in the same path that the given item exists at on the backend.

In the case of slow dynamic content, proxy_cache is more appropriate, as it supports expiry of the cache.

An example of where proxy_store is more useful might be a mirror of rpm files where one filename/version will never need to be expired.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.