I’ve been thinking of trying to conserve memory-heavy unicorn instances by configuring my external nginx (which I already have for serving 502 maintenance page and for correctly attributing IPv6 addresses) to also serve requests for images; with the intent of getting much of the value of moving them to S3 (or compatible object service) but still keeping the site self-contained on my server. (This wouldn’t move other site assets off of unicorns, but those are cached well from page to page, so that’s a much smaller overall cost in unicorns.)
Just like pointing external nginx at a socket in /var/discourse/shared I would serve /uploads from /var/discourse/shared/$container/uploads
I don’t see mention here on meta that anyone has done this, though my search foo might be weak. Am I missing any reasons this would not work, or would work poorly in practice?
If you want to help your unicorns, one thing that actually helps is Enable a CDN for your Discourse, as it will cache the few assets that are served on unicorns like the stylesheets.
I would guess that enabling caching on the external nginx would have the same benefit with respect to loading the unicorns, without having to set up a CDN. I see cache control headers on all the javascript assets, so I might give this a try…
… well, I see the internal nginx is also already using proxy_cache with a 7d validity for non-error requests:
location ~ ^/(svg-sprite/|letter_avatar/|letter_avatar_proxy/|user_avatar|highlight-js|stylesheets|theme-javascripts|favicon/proxied|service-worker) {
...
# note x-accel-redirect can not be used with proxy_cache
proxy_cache one;
proxy_cache_key "$scheme,$host,$request_uri";
proxy_cache_valid 200 301 302 7d;
proxy_cache_valid any 1m;
proxy_pass http://discourse;
break;
}
How does a CDN help with unicorns in that case? I see stylesheets in that list.
