Ludo', On 21/03/17 17:43, Ludovic Courtès wrote: > I think there’s room for improvement in our nginx config at > . > > For instance, I just discovered ‘proxy_cache_lock’ while looking at > ; looks useful > in reducing load on hydra.gnu.org. Surely there are other ways to tweak > caching. Indeed! For reference, here's my cache configuration. That's right. Now you can all¹ steal some criminally overpriced Belgian bandwidth! server { server_name substitutes.tobias.gr; listen [::]:443 ssl http2; listen 443 ssl http2; # FIXME move to main LE cert ssl_certificate substitutes.pem; ssl_certificate_key substitutes.key; # "" means ‘inherit from upstream’ here. add_header Cache-Control ""; # So does ‘off’. This is all a bit hacky. expires off; proxy_hide_header Set-Cookie; proxy_ignore_headers Set-Cookie; # Almost all traffic is already compressed. gzip off; ... location / { limit_except GET { deny all; } proxy_pass SUPER_SEKRIT_BACKEND; # https://www.nginx.com/blog/nginx-caching-guide add_header X-Cache-Status $upstream_cache_status; proxy_cache default; # We allow only GET requests, so don't waste key space: proxy_cache_key "$request_uri"; proxy_cache_lock on; proxy_cache_lock_timeout 3h; #yolo proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; } ... } I'm sure it's hardly optimal (or, erm, ‘good’) either but it works. > Besides, I’d like to use ‘guix publish’ on hydra.gnu.org. I suspect > it’s going to be faster than Starman (the HTTP server behind Hydra), and > also it uses an in-process gzip by default, as opposed to bzip2 which is > what Hydra uses (better compression ratio, but super CPU-intensive). Back when I used Hydra-the-software I do so briefly and I think it worked. But no hard tests. > At any rate, clients should not paper over server-side performance > issues IMO. Entirely off-topic, but this 'tude is a part of what drew me to Guix in the first place. So, like, thanks, in general :-) Kind regards, T G-R ¹: Just put it *after* mirror.hydra.gnu.org, OK?