11

ロード バランサーの背後に 2 台のサーバーがあります。各サーバーはmemcachedサーバーを実行しており、設定ファイル（両方のサーバーで同一）には両方が定義されています（つまり、共有キャッシュ）。

クライアントが複数回ダウンロードする必要がないように、生成されたファイルへのパスをサーバー上で同一にする必要があります。

これを機能させるには、djangoコンプレッサーの仕組みを理解する必要があります。

  • djangoコンプレッサーのキャッシュの実際の目的は何ですか?
  • ファイルの内容はキャッシュとファイルシステムの両方に保存されていますか?
    • もしそうなら、どちらが最初に起こりますか?
  • ここで正しい質問をしていることを願っています。自由に追加してください。

これよりも詳細で、より適切に構築されたシーケンスがあれば、非常に役立ちます。

編集

  • サーバーは両方ともmemcachedサーバーを共有しているため、設定する必要がありますかCOMPRESS_CACHE_KEY_FUNCTION = 'compressor.cache.socket_cachekey'(開発ブランチを参照)、または同じキャッシュキーを使用すると、同じファイル名を持つという私のポイントに貢献しますか?
  • 私がこれを理解している方法では、mtime はソース js/css ファイルから収集され、それらが変更された可能性があるかどうかを判断し、それらから新しいファイルを生成する必要があります。正しい？
    • これはおそらく、すべてのロードで発生するわけではありません。それはいつ起こりますか？
4

3 に答える 3

12

開発ブランチには、cssハッシュ方式を変更するための新しいオプションがあります。 https://github.com/jezdez/django_compressor

フィルタ/css_default.pyの61行目を参照してください

私が使用している設定：

COMPRESS_ENABLED = True
COMPRESS_OFFLINE = False
COMPRESS_STORAGE = 'compressor.storage.GzipCompressorFileStorage'
COMPRESS_CSS_HASHING_METHOD = 'hash' # not using mtime since it differs between servers.

とにかくmtimeを使用してハッシュキーが生成されることはないため、jsファイルにはこのようなオプションはありません。

これは私のロードバランサーの背後で完全に機能します。

これが書かれているとき、以下は開発ブランチの最新のコミットです：https ://github.com/jezdez/django_compressor/commit/d48bc5f45d5a55b0f826eb605ccf09a6bf33fcb9

于 2011-09-05T14:44:57.200 に答える
4

同一のキャッシュ ファイルが必要な場合は、両方のサーバーで同一の入力があることを確認する必要があります。

以下を確認する必要があります。

  • 両方のサーバーでコード{% compress %}...{% endcompress %}が同一である場合 (両方のサーバーに一度に展開する場合)
  • すべての .css/.js ファイルが両方のサーバーで同一である場合 (一度に両方のサーバーにデプロイする場合)
  • .css/.js ファイルの mtime (時刻の変更) が両方のサーバーで同一である場合 (デプロイ スクリプトがそれらに影響を与え、現在の日付を設定する可能性があります)

この要件がすべて満たされていれば、生成されるファイルは同一 (内容と名前) になります。

"stat" unix コマンドを使用して mtime を確認できます。

質問への回答:

  • django-compressor のキャッシュの目的は、ファイル システムからの読み取りを減らすことです。
  • コードを組み合わせて生成されたファイルは、ファイルシステムにのみ保存されます。

編集：

ロードバランサーの背後にある私の Web サイトの 1 つで確認しました。.css ファイルのファイル名は異なりますが、.js のファイル名は同じです。

.css ファイルの場合、プリプロセッサ (http://lesscss.org/) を使用するため、mtime に影響します。

編集（トピックの開発後）：

キャッシュには何がありますか?

ドキュメントにより、django-compressor はキャッシュに 2 つの異なるものを保存します。

  • キャッシュされたファイルの mtime (COMPRESS_MTIME_DELAY 秒ごとに再チェック)

  • 完全に生成されたコード ie.:

    <link rel="stylesheet" href="http://cdn.inprl.pl/CACHE/css/117f97d818b8.css" type="text/css">

次のキャッシュ使用により、django-compressor はファイルシステムへの読み取り回数を 0 に減らします。メモリからの読み取りはファイルシステムからの読み取りよりも数百倍高速であるため、これはページ速度にとって不可欠です。また、ファイルシステムがボトルネックになることがよくあります。

どのようにキャッシュに保存されますか?

django-compress は、生成されたキーを使用してキャッシュにコードを保存しています。キーは次のものから生成されます。

  • コードイン{% compress %}...{% endcompress %}
  • で言及されているファイルの mtime{% compress %}...{% endcompress %}

したがって、一貫した応答が必要な場合は、すべてのサーバーで同じでなければなりません。

PS。

サーバーの制約 (mtime など) を確認し、一致する場合はここに情報を投稿してください。

おそらく来週、私のサイトで同じ問題を修正する予定です。その後、追加の詳細を投稿します。

于 2011-08-30T18:58:51.800 に答える
0

すべきことは、すべての圧縮ファイルを、ロード バランサーの背後にあるコンピューティング インスタンスの外部にあるストレージに配置することです。たとえば、Amazon S3 を使用して、アプリケーションの残りの部分とは別のサブドメインにすべてのファイルを保存します。

http://myapp.comロード バランサーを指すhttp://s3.myapp.comことも、Amazon S3 などのストレージを指すことも同様です。異なるインスタンスに複数の異なるバージョンを保存することについて心配する必要はありません。

ここでは、Djangoで Amazon S3、Gzip 圧縮、および django-compressor をセットアップする方法の完全なガイドを見つけることができます。

于 2015-05-06T17:56:27.987 に答える