mcdanlj
2021 年 1 月 30 日午後 2:13
1
メモリを大量に消費する Unicorn インスタンスを節約するために、すでに 502 メンテナンスページの提供や IPv6 アドレスの正しい割り当てに使用している外部 Nginx を設定し、画像のリクエストもここで処理するようにすることを検討しています。その目的は、S3（または互換性のあるオブジェクトストレージサービス）に移行した場合の恩恵の多くを得つつ、サイトをサーバー上で自己完結させたままにすることです（これにより他のサイトアセットが Unicorn から外れるわけではありませんが、それらはページ間でよくキャッシュされるため、Unicorn への負荷は全体的に小さくなります）。
/var/discourse/shared 内のソケットを外部 Nginx が指すのと同様に、/uploads を /var/discourse/shared/$container/uploads から提供しようと考えています。
Meta でこれを実践したという話は見当たりませんが、私の検索能力が不十分なのかもしれません。このアプローチが機能しない、または実際にはうまくいかない理由が見当たらないでしょうか？
Falco
2021 年 1 月 30 日午後 2:30
2
コンテナ内の内部 nginx を使用して、すでに画像を提供しています。
mcdanlj
2021 年 1 月 30 日午後 3:16
3
ああ、少なくともこの素晴らしいアイデアを持った次の人が検索したときに、これを見つけられるようになりますね。本当にありがとうございます！
Falco
2021 年 1 月 30 日午後 3:16
4
ユニコーンをサポートしたい場合、実際に効果的な方法は、Discourse に対して CDN を有効にする ことです。これにより、スタイルシートなど、ユニコーンで提供される少数のアセットがキャッシュされます。
mcdanlj
2021 年 1 月 30 日午後 4:29
5
外部の nginx でキャッシングを有効にすれば、CDN を設置しなくてもユニコーンの読み込みにおいて同様の効果が得られると思います。すべての JavaScript アセットにキャッシュ制御ヘッダーが設定されているので、試してみようかと考えています。
…さて、内部の nginx もすでに proxy_cache を使用しており、エラー以外のリクエストに対して 7 日間の有効期限を設けていることが分かりました。
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;
}
その場合、CDN はユニコーンの処理にどのように役立つのでしょうか？リストに stylesheets が含まれているのを見ています。
