web-dev-qa-db-ja.com

画像をキャッシュするリバースプロキシの設定

私は簡単なPythonサーバーを作成して、リサンプリングされた画像を提供します。たとえば、URLはhttp://images.domain.com/resample/100x100/9f362e1994264321.jpgのようになります。画像のリサンプリングにはコストがかかるため、キャッシュレイヤーが必要です。 nginxのreverse-proxyがこれに適したオプションであるように、そして here と here は開始するのに良い場所のように見えます。

ただし、問題があります。何百万もの画像があるため、http://images.domain.com/resample/100x100/9f362e1994264321.jpgをファイルシステムに/home/nginx/cache/resample/100x100/9f362e1994264321.jpg（またはそのようなもの）として保存すると、最終的にcache/resample/100x100/には何百万ものファイルが含まれ、ファイルの検索が行われます非常に非効率的です。

元の画像を保存する際に、9f/36/9f362e1994264321.jpgなどの多くのサブディレクトリにそれらを配布して、この問題に対処します。ただし、nginxで同じように実行する方法がわかりません。同様にURLを変更することもできます。それが唯一の解決策である場合は変更しますが、URLをできるだけきれいに保ちたいと思います。

Nginxでこれを行うことはできますか？ nginxを使用していない場合、ワニスのような他のことを行うことはできますか？

nginxreverse-proxycache
7
Theron Luhn

代わりにいくつかの無関係なリンクをググって、あなたは間違いなく ngx_http_proxy_module.html に関するドキュメントを読んだはずです。

ディレクティブ_proxy_cache_はまさに必要なものです。構成は次のようになります。

_http {

    # ...

    proxy_cache_path /var/www/cache levels=1:2 keys_zone=imgcache:10m max_size=1000m inactive=720m;
    proxy_temp_path /var/www/cache/tmp;

    # ...

    server {

        # ...

        location /resample {
            proxy_pass          http://bla.bla.my.backend;
            proxy_cache         imgcache;
            #proxy_cache_key    $scheme$proxy_Host$request_uri;
            #proxy_cache_valid 200 302 60m;
            #proxy_cache_valid 404 10m
        }

        # ...

    }

}
_

_/var/www/cache_フォルダには、2つのレベルのディレクトリ構造が作成されます。そして、キャッシュされた http://mysite.com/resample/dir/file.jpg の応答は、_proxy_cache_key_値のmd5として保存されます。たとえば、上記の_#proxy_cache_key $scheme$proxy_Host$request_uri;_のコメントを解除すると、応答はファイル/ var/www/cache/f/08/8db24849a311cc3314955992686d308fにキャッシュされます

MD5 ("http://bla.bla.my.backend/resample/dir/file.jpg") = 8db24849a311cc3314955992686d308fとlevel = 1：2はdir構造に変換されるため、最後から文字を数えます... 08f-> f/08/md5value

7
cadmi

ファイルの検索が非常に非効率になります。

これは時期尚早の最適化のように聞こえます。

これが実行しているOSに関する情報を提供していません。 Varnishについて言及しているので、これはUnixの風味だと思います。 Linuxであると仮定します（ただし、これのほとんどは他のOSにも適用されます）。

実際にそれを測定し、これをパス書き換えアプローチと比較しましたか？パフォーマンスが低下している場合は、非常に古いファイルシステムで実行されている可能性があります（または、部分的なパッチによってアップグレードされたファイルシステム）。 ext4またはBTRFSを使用すると、測定可能な違いが見られるとは思いません。

しかし、それは要点の外です。リバースプロキシは、大量のファイルをキャッシュしている可能性があることを認識しており、必ずしもURLパスを直接ファイルシステムパスにマップするわけではありません。

キャッシュによって管理される非常に多数のファイルで問題が発生しますが、これらはVFS /方法論に関係しています。 vfs_cache_pressureを減らすと改善するはずです。

1
symcbean