Ubuntu 14.04でApacheコンテンツキャッシュを構成する方法

キャッシングとは何ですか?

キャッシュは、一般的に要求されるコンテンツをより高速なアクセスを可能にする方法で一時的に保存できるようにすることで、サーバーのパフォーマンスを向上させる方法です。 これにより、リソースを大量に消費する操作が排除されるため、処理と配信が高速化されます。

効果的なキャッシュルールを作成することにより、キャッシュに適したコンテンツが保存され、応答時間が改善され、リソースが節約され、負荷が最小限に抑えられます。 Apacheは、さまざまな種類の操作を高速化するのに適したさまざまなキャッシュを提供します。 このガイドでは、Ubuntu 14.04でさまざまなキャッシュモジュールを使用してApache 2.4を構成する方法について説明します。

一般的なキャッシュ戦略の開発の詳細については、this articleを確認してください。

Apacheのキャッシュの概要

Apacheは、洗練された拡張性のさまざまなレベルでコンテンツをキャッシュできます。 プロジェクトは、コンテンツをキャッシュする方法に従ってこれらを3つのグループに分けます。 一般的な内訳は次のとおりです。

  • File Caching:最も基本的なキャッシュ戦略。これは、サーバーの起動時にファイルまたはファイル記述子を開き、アクセスを高速化するためにそれらを使用可能な状態に保つだけです。

  • Key-Value Caching:主にSSLおよび認証キャッシングに使用されます。Key-Valueキャッシングは、繰り返し計算するのにコストがかかるアイテムを格納できる共有オブジェクトモデルを使用します。

  • Standard HTTP caching:最も柔軟で一般的に有用なキャッシュメカニズムであるこのスリーステートシステムは、応答を保存し、期限切れになったときにそれらを検証できます。 これは、特定のニーズに応じて、パフォーマンスまたは柔軟性のために構成できます。

上記の説明をざっと見てみると、上記の方法にはいくつかの重複があることがわかりますが、同時に複数の戦略を使用することが役立つ場合もあります。 たとえば、SSLセッションにキーと値のストアを使用し、応答用の標準HTTPキャッシュを有効にすると、データソースの負荷を大幅に軽減し、クライアントの多くのコンテンツ配信操作を高速化できます。

これで、Apacheの各キャッシュメカニズムを幅広く理解できたので、これらのシステムをさらに詳しく見てみましょう。

ファイルキャッシング

総括

  • Primary modules involvedmod_file_cache

  • Main use cases:サーバーの起動時にファイルの内容またはファイル記述子を保存します。 これらは、サーバーが再起動されるまで確実に変更できない静的な表現です。

  • Features:シンプルで、遅いファイルシステムのパフォーマンスを向上させます

  • Drawbacks:実験的な機能、ファイルシステムの更新に応答しない、オペレーティングシステムの制限内に収まるように慎重に使用する必要があり、静的ファイルでのみ使用できます

詳細

mod_file_cacheモジュールは主に、ファイルシステムが遅いサーバーでのファイルアクセスを高速化するために使用されます。 2つの構成ディレクティブを選択できます。どちらも、ファイルが要求されたときではなく、サーバーが起動されたときに作業の一部を実行することにより、静的ファイルを提供するプロセスを加速します。

CacheFileディレクティブは、アクセスを高速化するディスク上のファイルへのパスを指定するために使用されます。 Apacheが開始されると、Apacheは指定された静的ファイルを開き、ファイルハンドルをキャッシュします。これにより、要求されたときにファイルを開く必要がなくなります。 この方法で開くことができるファイルの数は、オペレーティングシステムによって設定された制限に従います。

MMapFileディレクティブは、Apacheが最初に起動されたときにもファイルを開きます。 ただし、MMapFileは、ファイルハンドラだけでなく、ファイルの内容をメモリにキャッシュします。 これにより、これらのページのパフォーマンスが向上しますが、いくつかの重大な制限があります。 使用したメモリ量の記録は保持されないため、メモリが不足する可能性があります。 また、子プロセスは割り当てられたメモリをコピーするため、最初に予想されるよりも速くリソースが枯渇する可能性があることに注意してください。 このディレクティブは慎重に使用してください。

これらのディレクティブは、Apacheの起動時にのみ評価されます。 これは、Apacheが起動後に行われた変更を取得するのに信頼できないことを意味します。 これらは、Apacheセッションの存続期間中は変更されない静的ファイルでのみ使用してください。 ファイルの変更方法によっては、サーバーに変更が通知される場合がありますが、これは予期された動作ではなく、常に正しく動作するわけではありません。 これらのディレクティブに渡されたファイルを変更する必要がある場合は、変更が行われた後にApacheを再起動します。

ファイルキャッシュを有効にする方法

ファイルのキャッシュは、mod_file_cacheモジュールによって提供されます。 この機能を使用するには、モジュールを有効にする必要があります。

Ubuntu 14.04を実行すると、モジュールはインストールされますが、Apacheをインストールすると無効になります。 次のように入力して、モジュールを有効にできます。

sudo a2enmod file_cache

その後、メイン構成ファイルを編集して、ファイルキャッシュディレクティブを設定する必要があります。 次を入力してファイルを開きます。

sudo nano /etc/apache2/apache2.conf

ファイルハンドルキャッシュを設定するには、CacheFileディレクティブを使用します。 このディレクティブは、次のように、スペースで区切られたファイルパスのリストを取ります。

/etc/apache2/apache2.conf

CacheFile /var/www/html/index.html /var/www/html/somefile.index

サーバーを再起動すると、Apacheはリストされたファイルを開き、アクセスを高速化するためにファイルハンドルをキャッシュに保存します。

代わりに、いくつかのファイルをメモリに直接マップする場合は、MMapFileディレクティブを使用できます。 構文は基本的に最後のディレクティブと同じで、ファイルパスのリストを単純に受け取ります。

/etc/apache2/apache2.conf

MMapFile /var/www/html/index.html /var/www/html/somefile.index

実際には、同じファイルセットに対してbothCacheFileMMapFileを構成する理由はありませんが、異なるファイルセットで両方を使用できます。

終了したら、ファイルを保存して閉じることができます。 次を入力して、構成ファイルの構文を確認します。

sudo apachectl configtest

最後の行にSyntax OKと表示されている場合は、Apacheインスタンスを安全に再起動できます。

sudo service apache2 restart

Apacheは再起動し、使用したディレクティブに応じてファイルの内容またはハンドラーをキャッシュします。

Key-Valueキャッシング

総括

  • Primary modules involvedmod_socache_dbmmod_socache_dcmod_socache_memcachemod_socache_shmcb

  • Supporting modules involvedmod_authn_socachemod_ssl

  • Main use cases:SSLセッションまたは認証の詳細の保存、SSLステープリング

  • Features:複雑なリソースを格納するための共有オブジェクトキャッシュ。SSLセッションのキャッシュとステープリングを支援でき、柔軟なバックエンド

  • Drawbacks:検証メカニズムがなく、パフォーマンスが高く柔軟なバックエンド用に個別のソフトウェアを構成する必要があります。コードにいくつかのバグがあります

詳細

キーと値のキャッシュはファイルのキャッシュよりも複雑で、より焦点を絞った利点があります。 共有オブジェクトキャッシュとも呼ばれるApacheのキーバリューキャッシュは、主に、コンテンツ自体ではなく、コンテンツへのクライアントアクセスの設定に伴う高価な操作を繰り返すことを避けるために使用されます。 特に、認証の詳細、SSLセッションをキャッシュし、SSLステープルを提供するために使用できます。

Note

[.note]#現在、everyの共有オブジェクトキャッシュプロバイダーにいくつかの問題があります。 問題への参照の概要を以下に示します。 この機能を有効にするかどうかを評価するときは、これらを考慮に入れてください。

実際のキャッシングは、共有オブジェクトキャッシングプロバイダーモジュールの1つを使用して実現されます。 これらは:

  • mod_socache_dbm:このバックエンドは単純なdbmデータベースエンジンを使用します。これは、ハッシュと固定サイズのバケットを利用するファイルベースのKey-Valueストアです。 このプロバイダーはいくつかのメモリリークに悩まされているため、ほとんどの場合、代わりにmod_socache_shmcbを使用することをお勧めします。

  • mod_socache_dc:このプロバイダーはdistcacheセッションキャッシュソフトウェアを使用します。 このプロジェクトは2004年以降更新されておらず、一部のディストリビューションではパッケージ化されていないため、十分な注意を払って使用してください。

  • mod_socache_memcache:これはアイテムを格納するためにmemcache分散メモリオブジェクトキャッシュを使用します。 これは、複数のサーバー間の分散キャッシュに最適なオプションです。 現在、エントリは適切に期限切れになりませんが、patchは、問題を修正するApacheのバージョン管理のトランクにコミットされました。

  • mod_socache_shmcb:現在、これはKey-Valueキャッシュに最適なオプションです。 これは共有メモリ内の循環バッファにキャッシュされ、いっぱいになるとエントリが削除されます。 現在、entries over 11k in sizeでチョークしています。

上記のプロバイダーモジュールに加えて、キャッシュされるオブジェクトに応じて追加のモジュールが必要になります。 たとえば、SSLセッションをキャッシュしたり、SSLステープルを構成したりするには、mod_sslを有効にする必要があります。これにより、それぞれSSLSessionCacheおよびSSLStaplingCacheディレクティブが提供されます。 同様に、認証キャッシュを設定するには、mod_authn_socacheモジュールを有効にして、AuthnCacheSOCacheディレクティブを設定できるようにする必要があります。

キーと値のキャッシュを有効にする方法

上記のバグと警告を念頭に置いて、Apacheでこのタイプのキャッシングを設定したい場合は、以下に従ってください。

キーと値のキャッシュを設定するために使用される方法は、それが何に使用され、どのプロバイダーを使用しているかによって異なります。 以下では、認証キャッシュとSSLセッションキャッシュの両方の基本について説明します。

現在、キャッシュプロバイダーへの引数の受け渡しを妨げるa bug with authentication cachingがあります。 そのため、フォールバックするデフォルト設定を提供しないプロバイダーには問題があります。

認証キャッシュ

認証キャッシュは、LDAP認証やデータベース認証などの高価な認証方法を使用している場合に役立ちます。 これらのタイプの操作は、認証要求が行われるたびにバックエンドにヒットする必要がある場合、パフォーマンスに大きな影響を与える可能性があります。

キャッシュの設定には、既存の認証設定の変更が含まれます(このガイドでは認証の設定方法については説明しません)。 変更自体は、バックエンドの認証方法に関係なくほぼ同じです。 デモにはmod_socache_shmcbを使用します。

まず、次のように入力して、authn_socacheモジュールとmod_socache_shmcbプロバイダーモジュールを有効にします。

sudo a2enmod authn_socache
sudo a2enmod socache_shmcb

メインのApache構成ファイルを開いて、認証で使用するこの共有キャッシュバックエンドを指定できるようにします。

sudo nano /etc/apache2/apache2.conf

内部で、ファイルの先頭に向かって、AuthnCacheSOCacheディレクティブを追加します。 shmcbをプロバイダーとして使用するように指定します。 前述のオプションの受け渡しを妨げるバグが、これを読むまでに修正されている場合、キャッシュの場所とサイズを指定できます。 数値はバイト単位であるため、コメント付きの例では512キロバイトのキャッシュが生成されます。

/etc/apache2/apache2.conf

AuthnCacheSOCache shmcb

# If the bug preventing passed arguments to the provider gets fixed,
# you can customize the location and size like this
#AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)

完了したら、ファイルを保存して閉じます。

次に、認証が構成されている仮想ホスト構成ページを開きます。 000-default.conf仮想ホスト構成を使用していると想定しますが、環境を反映するように変更する必要があります。

sudo nano /etc/apache2/sites-enabled/000-default.conf

認証を構成した場所で、ブロックを変更してキャッシュを追加します。 具体的には、AuthnCacheProvideForを追加して、キャッシュする認証ソースを指定し、AuthnCacheTimeoutでキャッシュタイムアウトを追加し、socacheAuthBasicProviderリストの前に追加する必要があります。従来の認証方法。 結果は次のようになります。

/etc/apache2/sites-enabled/000-default.conf



    . . .

    
        AuthType Basic
        AuthName "Restricted Files"
        AuthBasicProvider socache file
        AuthUserFile /etc/apache2/.htpasswd
        AuthnCacheProvideFor file
        AuthnCacheTimeout 300
        Require valid-user
    

上記の例はファイル認証のためのものであり、おそらくキャッシュによるメリットはあまりありません。 ただし、他の認証方法を使用する場合、実装は非常に似ている必要があります。 唯一の実質的な違いは、上記の例の「ファイル」仕様がどこにあるかであり、代わりに他の認証方法が使用されます。

ファイルを保存して閉じます。 Apacheを再起動して、キャッシュの変更を実装します。

sudo service apache2 restart

SSLセッションキャッシング

SSL接続を確立するために実行する必要があるハンドシェイクには、大きなオーバーヘッドが伴います。 したがって、セッションデータをキャッシュして以降のリクエストの初期化手順を回避すると、このペナルティを回避できる可能性があります。 共有オブジェクトキャッシュは、これに最適な場所です。

ApacheサーバーにSSLがすでに構成されている場合は、mod_sslが有効になります。 Ubuntuでは、これはssl.confファイルが/etc/apache2/mods-enabledディレクトリに移動されたことを意味します。 これは実際にすでにキャッシュを設定しています。 内部には、次のような行が表示されます。

/etc/apache2/mods-enabled/ssl.conf

. . .

SSLSessionCache         shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout  300

. . .

これは実際にセッションキャッシングを設定するのに十分です。 これをテストするには、OpenSSLの接続クライアントを使用できます。 タイプ:

openssl s_client -connect 127.0.0.1:443 -reconnect -no_ticket | grep Session-ID

セッションIDがすべての結果で同じ場合、セッションキャッシュは正しく機能しています。 CTRL-Cを押して終了し、ターミナルに戻ります。

標準HTTPキャッシング

総括

  • Primary modules involvedmod_cache

  • Supporting modules involvedmod_cache_diskmod_cache_socache

  • Main use cases:一般的なコンテンツのキャッシュ

  • Features:HTTPキャッシングヘッダーを正しく解釈でき、古いエントリを再検証でき、ニーズに応じて最大速度または柔軟性を実現するためにデプロイできます

  • Drawbacks:設定が正しくないと機密データが漏洩する可能性があります。キャッシュポリシーを正しく設定するには、追加のモジュールを使用する必要があります

詳細

HTTPプロトコルは、コンテンツ配信パス全体で応答をキャッシュするメカニズムを推奨し、提供します。 コンテンツに触れるコンピューターは、コンテンツの発信元で設定されているキャッシュポリシーとコンピューターの独自のキャッシュルールに応じて、一定期間、各アイテムをキャッシュできます。

Apache HTTPキャッシングメカニズムは、表示されるHTTPキャッシングポリシーに従って応答をキャッシュします。 これは、配信に関与する中間サーバーが従うのと同じルールを順守する汎用キャッシングシステムです。 これにより、このシステムは非常に柔軟で強力になり、コンテンツに既に設定しているヘッダーを活用できます(これを行う方法については後述します)。

ApacheのHTTPキャッシュは「3状態」キャッシュとも呼ばれます。 これは、保存されているコンテンツが3つの状態のいずれかになる可能性があるためです。 それは新鮮である可能性があり、それ以上のチェックなしでクライアントへの提供が許可されることを意味します。 。

次のリクエストでコンテンツが古くなった場合、キャッシュはオリジンのコンテンツをチェックすることでコンテンツを再検証できます。 変更されていない場合は、鮮度の日付をリセットし、現在のコンテンツを配信できます。 それ以外の場合、変更されたコンテンツを取得し、キャッシュポリシーで許可されている期間保存します。

モジュールの概要

HTTPキャッシングロジックは、mod_cacheモジュールを介して利用できます。 実際のキャッシングは、キャッシングプロバイダーの1つを使用して行われます。 通常、キャッシュはmod_cache_diskモジュールを使用してディスクに保存されますが、共有オブジェクトのキャッシュはmod_cache_socacheモジュールを介して利用することもできます。

mod_cache_diskモジュールはディスクにキャッシュされるため、リモートの場所からコンテンツをプロキシする場合、動的プロセスからコンテンツを生成する場合、または通常のコンテンツよりも高速なディスクにキャッシュすることで処理速度を上げようとする場合に役立ちます。に常駐します。 これは最もよくテストされたプロバイダーであり、ほとんどの場合、おそらく最初の選択肢です。 キャッシュは自動的にクリーンアップされないため、キャッシュをスリム化するために、htcachecleanというツールを時々実行する必要があります。 これは、手動で実行するか、通常のcronジョブとして設定するか、デーモンとして実行できます。

mod_cache_socacheモジュールは、共有オブジェクトプロバイダーの1つ(前のセクションで説明したものと同じもの)にキャッシュします。 これは、mod_cache_diskよりもパフォーマンスが向上する可能性があります(選択されている共有キャッシュプロバイダーによって異なります)。 ただし、はるかに新しく、前述のバグがある共有オブジェクトプロバイダーに依存しています。 mod_cache_socacheオプションを実装する前に、包括的なテストを行うことをお勧めします。

HTTPキャッシュの配置

ApacheのHTTPキャッシュは、ニーズに応じて2つの異なる構成で展開できます。

CacheQuickHandlerが「オン」に設定されている場合、キャッシュはリクエスト処理プロセスの非常に早い段階でチェックされます。 コンテンツが見つかった場合、それ以上の処理なしで直接配信されます。 これは、非常に高速であることを意味しますが、コンテンツの認証などのプロセスを許可しないことも意味します。 通常は認証またはアクセス制御を必要とするコンテンツがキャッシュにある場合、CacheQuickHandlerが「オン」に設定されていれば、認証なしでanyoneにアクセスできます。

基本的に、これはWebサーバーの前にある個別のキャッシュをエミュレートします。 Webサーバーが何らかの条件付きチェック、認証、または承認を行う必要がある場合、これは起こりません。 Apacheは、<Location>または<Directory>ブロック内のディレクティブを評価しません。 CacheQuickHandlerdefaultによって「オン」に設定されていることに注意してください。

CacheQuickHandlerが「オフ」に設定されている場合、キャッシュは要求処理シーケンスのかなり後の段階でチェックされます。 この構成は、Apache処理ロジックと実際のコンテンツの間にキャッシュを配置すると考えてください。 これにより、キャッシュからコンテンツを取得する前に、従来の処理ディレクティブを実行できます。 これを「オフ」に設定すると、要求をより深く処理する機能と少し速度が低下します。

標準HTTPキャッシュを構成する方法

キャッシュを有効にするには、mod_cacheモジュールとそのキャッシュプロバイダーの1つを有効にする必要があります。 上で述べたように、mod_cache_diskは十分にテストされているので、それに依存します。

モジュールの有効化

Ubuntuシステムでは、次のように入力してこれらのモジュールを有効にできます。

sudo a2enmod cache
sudo a2enmod cache_disk

これにより、次回サーバーを再起動したときにキャッシュ機能が有効になります。

また、必要に応じてキャッシュを削減するために使用されるhtcachecleanユーティリティを含むapache2-utilsパッケージをインストールする必要があります。 これをインストールするには、次のように入力します。

sudo apt-get update
sudo apt-get install apache2-utils

グローバル構成の変更

キャッシングの設定のほとんどは、個々の仮想ホスト定義またはロケーションブロック内で行われます。 ただし、mod_cache_diskを有効にすると、いくつかの一般的な属性を指定するために使用できるグローバル構成も有効になります。 今すぐそのファイルを開いて見てみましょう。

sudo nano /etc/apache2/mods-enabled/cache_disk.conf

コメントを削除すると、ファイルは次のようになります。

/etc/apache2/mods-enabled/cache_disk.conf


    CacheRoot /var/cache/apache2/mod_cache_disk
    CacheDirLevels 2
    CacheDirLength 1

IfModuleラッパーは、mod_cache_diskモジュールが有効になっている場合にのみ、これらのディレクティブについて心配するようにApacheに指示します。 CacheRootディレクティブは、キャッシュが維持されるディスク上の場所を指定します。 CacheDirLevelsCacheDirLengthはどちらも、キャッシュディレクトリ構造の構築方法の定義に貢献します。

提供されているURLのmd5ハッシュが、データの保存に使用されるキーとして作成されます。 データは、各ハッシュの開始文字から派生したディレクトリに編成されます。 CacheDirLevelsは、作成するサブディレクトリの数を指定し、CacheDirLengthは、各ディレクトリの名前として使用する文字数を指定します。 したがって、上記のデフォルト値を持つb1946ac92492d2347c6235b4d2611184のハッシュは、b/1/946ac92492d2347c6235b4d2611184のディレクトリ構造にファイルされます。 通常、これらの値を変更する必要はありませんが、それらが何に使用されているかを知っておくと便利です。

Note

[.note]#CacheRoot値を変更する場合は、/etc/default/apache2ファイルを開き、選択内容に一致するようにHTCACHECLEAN_PATHの値を変更する必要があります。 これは定期的にキャッシュをクリーンアップするために使用されるため、キャッシュの正しい場所が必要です。

このファイルで設定できる他のいくつかの値は、Apacheがキャッシュにコミットするファイルサイズの範囲をバイト単位で設定するCacheMaxFileSizeCacheMinFileSize、およびCacheReadSizeCacheReadTimeです。 )s。これにより、クライアントに送信する前にコンテンツを待機してバッファリングできます。 これは、コンテンツがこのサーバー以外の場所にある場合に役立ちます。

仮想サーバーの変更

キャッシングの構成のほとんどは、仮想ホスト定義または特定のロケーションブロックのいずれかで、より詳細なレベルで行われます。

仮想ホストファイルの1つを開いて、フォローします。 このガイドのデフォルトファイルを使用していると仮定します。

sudo nano /etc/apache2/sites-enabled

ロケーションブロックの外側の仮想ホストブロックで、いくつかのキャッシュプロパティの構成を開始できます。 このガイドでは、より多くの処理が行われるように、CacheQuickHandlerをオフにすることを想定しています。 これにより、より完全なキャッシュルールを作成できます。

また、この機会にキャッシュロックを構成します。 これは、コンテンツがまだ有効であるかどうかを確認するためにコンテンツオリジンでチェックインするときにApacheが使用するファイルロックのシステムです。 このクエリが満たされている間に、同じコンテンツに対する追加のリクエストが入ると、バックエンドリソースへの追加のリクエストが発生し、負荷が急増する可能性があります。

検証中にリソースのキャッシュロックを設定すると、リソースが現在更新されていることがApacheに通知されます。 この間、失効したリソースには、その状態を示す警告ヘッダーが表示されます。 これは、/tmpフォルダー内のキャッシュロックディレクトリを使用して設定します。 ロックが有効であると見なされるまでに最大5秒かかります。 これらの例は、Apacheのドキュメントから直接取られたものであるため、私たちの目的に適しています。

また、ApacheにSet-Cookieヘッダーを無視し、それらをキャッシュに保存しないように指示します。 そうすることで、Apacheが誤ってユーザー固有のCookieを他の関係者に漏らすことを防ぎます。 Set-Cookieヘッダーは、ヘッダーがキャッシュされる前に削除されます。

/etc/apache2/sites-enabled/000-default.conf


    ServerAdmin [email protected]
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

この仮想ホストのキャッシングを実際に有効にする必要があります。 これは、CacheEnableディレクティブを使用して実行できます。 これが仮想ホストブロックに設定されている場合は、キャッシュ方法(diskまたはsocache)と、キャッシュする必要のある要求されたURIを指定する必要があります。 たとえば、すべての応答をキャッシュするには、これをCacheEnable disk /に設定できますが、応答を/public URIでのみキャッシュする場合は、これをCacheEnable disk /publicに設定できます。

特定のロケーションブロック内でキャッシュを有効にすることで、別のルートを使用します。 そうすることで、CacheEnableコマンドへのURIパスを指定する必要がなくなります。 その場所から提供されるURIはすべてキャッシュされます。 また、CacheHeaderディレクティブをオンにして、応答ヘッダーがキャッシュが要求の処理に使用されたかどうかを示すようにします。

設定するもう1つのディレクティブはCacheDefaultExpireです。これにより、コンテンツにExpiresヘッダーもLast-Modifiedヘッダーも設定されていない場合に、有効期限(秒単位)を設定できます。 同様に、CacheMaxExpireを設定して、アイテムが保存される時間を制限します。 Last-Modifiedの日付があり、有効期限がない場合にApacheが有効期限を作成できるように、CacheLastModifiedFactorを設定します。 この係数には、妥当な有効期限を設定するために変更してからの時間が乗算されます。

/etc/apache2/sites-enabled/000-default.conf


    ServerAdmin [email protected]
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

    
        CacheEnable disk
        CacheHeader on

        CacheDefaultExpire 600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5
    

必要なものをすべて設定したら、ファイルを保存して閉じます。

次のように入力して、構成全体の構文エラーを確認します。

sudo apachectl configtest

エラーが報告されない場合は、次を入力してサービスを再起動します。

sudo service apache2 restart

コンテンツの有効期限とキャッシュヘッダーの設定

上記の構成では、HTTPヘッダーに依存するHTTPキャッシュを構成しました。 ただし、提供しているコンテンツには、インテリジェントなキャッシュの決定に必要なExpiresまたはCache-Controlヘッダーが実際にはありません。 これらのヘッダーを設定するには、さらにいくつかのモジュールを利用する必要があります。

mod_expiresモジュールは、ExpiresヘッダーとCache-Controlヘッダーのmax-ageオプションの両方を設定できます。 mod_headersモジュールを使用して、より具体的なCache-Controlオプションを追加し、キャッシュポリシーをさらに調整できます。

これらのモジュールの両方を有効にするには、次のように入力します。

sudo a2enmod expires
sudo a2enmod headers

これらのモジュールを有効にした後、仮想ホストファイルを再び変更することができます。

sudo nano /etc/apache2/sites-enabled/000-default.conf

mod_expiresモジュールは、3つのディレクティブのみを提供します。 ExpiresActiveは、特定のコンテキストで有効期限処理を「オン」に設定することにより、有効期限処理をオンにします。 他の2つのディレクティブは互いに非常に似ています。 ExpiresDefaultディレクティブはデフォルトの有効期限を設定し、ExpiresByTypeはコンテンツのMIMEタイプに従って有効期限を設定します。 これらは両方とも、ExpiresCache-Controlの「max-age」を正しい値に設定します。

これらの2つの設定は、2つの異なる構文を取ることができます。 最初は単に「A」または「M」で、その後に秒数が続きます。 これにより、コンテンツがそれぞれ「アクセス」または「変更」された最後の時間に関連して有効期限が設定されます。 たとえば、これらの両方は、アクセスされてから30秒後にコンテンツを期限切れにします。

ExpiresDefault A30
ExpireByType text/html A30

他の構文では、より詳細な構成が可能です。 これにより、人間が計算しやすい秒以外の単位を使用できます。 また、「アクセス」または「変更」というフルワードも使用します。 有効期限設定全体は、次のように引用符で囲む必要があります。

ExpiresDefault "modification plus 2 weeks 3 days 1 hour"
ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"

ここでは、デフォルトの有効期限を設定します。 5分に設定することから始めて、慣れて間違えた場合にクライアントのコンピューターに非常に長い間保存されないようにします。 コンテンツに適したポリシーを選択する自信がついたら、これをより積極的なものに調整できます。

/etc/apache2/sites-enabled/000-default.conf


    ServerAdmin [email protected]
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

    
        CacheEnable disk
        CacheHeader on

        CacheDefaultExpire 600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5

        ExpiresActive on
        ExpiresDefault "access plus 5 minutes"
    

これにより、Expiresヘッダーが将来5分に設定され、Cache-Control max-age=300が設定されます。 キャッシュポリシーをさらに洗練するために、Headerディレクティブを使用できます。 mergeオプションを使用して、Cache-Controlオプションを追加できます。 これを複数回呼び出して、必要なポリシーを追加できます。 this guideをチェックして、コンテンツに設定するキャッシュポリシーについてのアイデアを入手してください。 この例では、他のキャッシュがコピーの保存を許可されていることを確認できるように、「パブリック」を設定します。

サイトの静的コンテンツにETagsを設定するには(検証に使用するため)、FileETagディレクティブを使用できます。 これは、静的コンテンツに対して機能します。 動的に生成されたコンテンツの場合、アプリケーションはETagsを正しく生成する責任があります。

ディレクティブを使用して、ApacheがEtagを計算するために使用する属性を設定します。 これは、ファイルのinodeが変更されるたびにETagを変更するかどうかに応じて、INodeMTimeSize、またはAllになります。その変更時間の変更、そのサイズの変更、または上記のすべて。 複数の値を指定できます。また、新しい設定の前に+または-を付けることで、子コンテキストで継承された設定を変更できます。 この目的のために、「すべて」を使用して、すべての変更が登録されるようにします。

/etc/apache2/sites-enabled/000-default.conf


    ServerAdmin [email protected]
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    CacheQuickHandler off

    CacheLock on
    CacheLockPath /tmp/mod_cache-lock
    CacheLockMaxAge 5

    CacheIgnoreHeaders Set-Cookie

    
        CacheEnable disk
        CacheHeader on

        CacheDefaultExpire 600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5

        ExpiresActive on
        ExpiresDefault "access plus 5 minutes"

        Header merge Cache-Control public
        FileETag All
    

これにより、Cache-Controlが既に持っている値に「public」(コンマで区切る)が追加され、静的コンテンツのETagが含まれます。

終了したら、ファイルを保存して閉じます。 次のように入力して、変更の構文を確認します。

sudo apachectl configtest

エラーが見つからなかった場合は、サービスを再起動してキャッシュポリシーを実装します。

sudo service apache2 restart

結論

Apacheでキャッシュを構成することは、オプションの数が多いため困難な作業のように思えます。 幸いなことに、単純に始めてから、複雑さが増すにつれて成長するのは簡単です。 ほとんどの管理者は、各キャッシュタイプを必要としません。

キャッシュを設定するときは、さまざまな実装の選択肢で迷子にならないように、解決しようとしている特定の問題に留意してください。 ほとんどのユーザーは、少なくともヘッダーを設定することで恩恵を受けます。 コンテンツをプロキシまたは生成している場合は、HTTPキャッシュを設定すると役立つ場合があります。 共有オブジェクトキャッシングは、バックエンドプロバイダーを使用している場合、SSLセッションや認証詳細の保存などの特定のタスクに役立ちます。 ファイルキャッシュは、おそらく低速なシステムのキャッシュに限定されます。

Related