Hi,

I am working on a small project and I am a bit baffled. Hoping someone can give me a bit of insight.

I've setup an nginx cache proxy upstream of an IIS ASP WinServer 2012 web server. For the most part things are working nicely. But I have a few weird issues.

- Intermittently (ie, maybe 3-5x per day) there is an outright fail to load some CSS asset content. This results in the page load looking gross because - the CSS is missing so the layout is broken. But - this is what I would call "intermittent" - it works for many ~thousands of loads per day without issue.

- I did a bit of debug noodling around yesterday, and - I am pretty sure that Nginx is *never* getting a cache hit for the CSS content in question. ie, if I visit the URL 3x in a row for the 'thing that fails intermittently" - I can see in my nginx logs, my visits are shown clearly, and it confirms that they are cache - misses.

- in contrast if I drop a small text file into the same directory where the CSS asset is being pulled - and hit that 3 times in a row. Then the first load of this test file is a "Miss" as expected; but then the next 2 are both 'hits' for cache.

- Possibly a related factor (this is my suspicion anyhow?) - the Windows web server is using a minification feature to automagically return minified CSS files as a batch / single minified content lump. So the way it is working presently,

http://web.server.name/path/to/css

(note there is no suffix .. such as .css)
on the IIS web server we are in iiswebroot/path/to/css
and inside the directory css are 6 .css files
and these are the things which are minified and returned as a single asset when you hit the URL,
http://web.server.name/path/to/css

I must admit, I had never seen this IIS feature in use before so it is new to me. I'm also slightly baffled/puzzled that it is returning the asset against the URL,

http://web.server.name/path/to/css

and not something like

http://web.server.name/path/to/css/minified-css-file-name.css

but anyhow, that is how the WebAdmin for this windows webserver set it up so I'm trying not to rock the boat on how it is setup and working.

Anyhow. Some relevant config stanzas for my nginx setup,
(not! my whole config - for brevity - just key bits to illustrate what is happening)

---paste---
# setup cache
proxy_cache_path /var/nginx-cache levels=1:2 keys_zone=STATIC:10m
inactive=24h max_size=1g;


# cache everything (it is all static) from this particular path
# (NOTE THIS IS WHERE THE CSS ASSET LIVES DESCRIBED ABOVE)
# ie /path/to/Content/
location ~* /Content/ {
proxy_pass https://www.servername.com;
proxy_set_header Host $host;
proxy_buffering on;
proxy_cache STATIC;
proxy_cache_valid any 24h;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
}

# Various static content types from all locations will be cached

location ~* \.(asa|asax|ascx|bin|bmp|browser|config|cs|cshtml|csproj|css|csv|dll|doc|docb|docm|docx|dot|dotm|dotx|drc|eot|exe|gif|htm|html|ico|jpeg|jpg|js|json|log|mdf|mng|ogg|otf|pdb|pdf|php|png|pot|potm|potx|ppam|pps|ppsm|ppsx|ppt|pptm|pptx|qt|resources|resx|rm|rmvb|roq|rsp|shtml|sld|sldm|sldx|svg|svi|swf|targets|ttf|txt|vob|webm|webp|well|woff|woff2|xla|xlam|xll|xlm|xls|xlsb|xlsm|xlsx|xlt|xltm|xltx|xlw|xml|yuv)$ {
proxy_pass https://www.servername.com;
proxy_set_header Host $host;
proxy_buffering on;
proxy_cache STATIC;
proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503 http_504;
}

#anything else goes to back end - ie - non static / things we don't wish to cache on the proxy
location / {
proxy_pass https://www.servername.com;
proxy_pass_header X-ThingeyBob-Real-IP;
proxy_set_header Host $host;
proxy_set_header X-ThingeyBob-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}




---end of config stanza---

so .. if anyone can comment,

- does nginx inherently just 'not cache a thing that looks like a directory path' - and I can't force it to do so - ? or is there some configuration tweak which might allow that to work ?

- will I need to have windows admin adjust the IIS Back-end host / so that the minified stuff will be returned with a format I might call 'more normal' - ie - minified-css-filename.css - for example ? (or do I just lack sufficient experience with IIS servers to understand what is 'normal' here :-) ?

Based on the fact we get intermittent fails right now, for this particular 'asset' - and zero cache hit behaviour, my working theory is that we have infrequent / intermittent issue with the back-end server failing to deliver the minified CSS file. For some 'unknown reason'. And so nginx has nothing to return to the external client human browser, and - the problem arises. But the windows admin seems to think this cannot be the case, it must be my config of nginx that is the problem. (sigh).

Any other comments suggestions are greatly welcome.

many thanks!

Tim

So, a little followup on this. In case anyone else finds themselves in the same situation. I dug into docs a bit more and reading, I realized I needed to look at the (!precise!) config for proxy_cache_key. A bit more reading of online docs / and some various online discussions.. I adjusted my config

# new setting that worked
proxy_cache_key "$host$uri$is_args$args";

# old setting that did not work
# proxy_cache_key "$scheme$host$request_uri";

then test/restart nginx; delete manually the content of the /path/to/cache/on/disk
... and happy days, I am now getting cache hits for the URL, http://web.server.name/path/to/css - whereas in the past I was getting MISS on the cache 100% of the time for this URL.

After making the adjustment, there was a plainly visible change to page load performance for the website. Everything moved from being "Meh-ok-good" performance to being "Wow-fast-visibly-snappy-quick". So this is nice.

After ~overnight things appear to be in a good place. So I think the issue is resolved.

So. I guess the answer to my post question, "what defines a cachable asset?" - the answer, is, whatever you configured your proxy_cache_key settings to be in your nginx setup. Woot.

Hope this info is of slight use-help-interest to someone else, sometime. Maybe.


Tim Chipman