9

私が考えることができる唯一の理由は、ETagの計算に費用がかかる可能性があるということです。ページが非常に速く変更される場合、ブラウザのキャッシュはによって無効になる可能性がありETagます。その場合、の計算ETagは時間の無駄になります。一方、304可能な場合に応答を与えることで、送信に費やされる時間を最小限に抑えることができます。ETagDjangoで実装したときに、が正味の勝者になる可能性が高い場合の適切なガイドラインは何CommonMiddlewareですか？

4

3 に答える 3

0

キャッシングを処理するには多くの方法があり、多くの場合アプリケーション固有です。最初のシナリオでUSE_ETAGSfromの使用を検討する方法を提案しdjango.middleware.common.CommonMiddlewareます。

  1. アプリケーションをキャッシュ可能なガンコーン インスタンスとキャッシュ不可のガンコーン インスタンスに分割します。リバース プロキシを使用してサイトを接続します。続いて、

  2. モデルの保存時にキャッシュを無効にするコードを書く。次のステップとして、

  3. 独自のカスタム キャッシング ミドルウェアを作成します。

于 2014-03-23T22:26:06.660 に答える
-2

なぜあなたが何かをしない理由を探しているのか理解できません。ただし、分析は完全ではありません。条件付きリクエスト/304 応答は、実際には、if-modified-since / if-none-match を削除した場合よりもアプリケーションの動作を大幅に遅くする可能性がありますが、検索エンジンを満足させ、サーバー間レプリケーション (CDN など)

C.

于 2010-05-05T13:21:03.563 に答える