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

Caching とは何ですか。

Caching とは、一般に要求されるコンテンツを、より高速にアクセスできる方法で一時的に保存できるようにして、サーバーのパフォーマンスを向上させる方法です。

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

一般的なキャッシュ戦略の開発についての詳細は、この記事をご覧ください。

An Introduction to Caching in Apache

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

• ファイルキャッシュ: 最も基本的なキャッシュ戦略で、サーバーの起動時にファイルまたはファイル記述子を単に開き、アクセスを高速化するためにそれらを利用可能な状態に維持するものです。
• Key-Value キャッシュ: 主に SSL および認証キャッシュに使用される Key-Value キャッシュは、繰り返し計算するのが高価なアイテムを保存できる共有オブジェクト モデルを使用します。
• 標準 HTTP キャッシュ: 最も柔軟で一般的に役立つキャッシュ機構で、このスリーステート システムは応答を保存して、期限が切れたときにそれを検証することが可能です。 これは、特定のニーズに応じて、パフォーマンスまたは柔軟性のために構成することができます。

上記の説明をざっと見ると、上記の方法がいくつか重複していること、また、同時に複数の戦略を使用することが有用である場合があることがわかるかもしれません。 例えば、SSL セッションに key-value ストアを使用し、レスポンスに標準 HTTP キャッシュを有効にすると、データソースから大きな負荷を取り除き、クライアントのために多くのコンテンツ配信操作をスピードアップできます。

さて、Apache の各キャッシュ機構について広く理解したところで、これらのシステムをより詳細に見ていきましょう。 mod_file_cache

主な使用例: サーバーの起動時にファイルのコンテンツまたはファイル記述子を保存する。

特徴: シンプル、遅いファイルシステムのパフォーマンスを向上させる

欠点: 実験的機能、ファイルシステムの更新に反応しない、オペレーティングシステムの制限に合うように控えめに使用しなければならない、静的ファイルにのみ使用できる

詳細

mod_file_cache モジュールは主に遅いファイルシステムのサーバーでファイルアクセスを高速化するのに使用されます。

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

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

これらのディレクティブは Apache が開始されたときにのみ評価されます。 つまり、Apache が起動した後に行われた変更を取り込むことは当てになりません。 これらは Apache のセッションの間だけ変更されない静的なファイルにのみ使用してください。 ファイルの変更方法によっては、サーバに変更が通知されるかもしれませんが、 これは期待された動作ではなく、常に正しく動作するわけではありません。 これらのディレクティブに渡されたファイルに変更を加えなければならない場合、 変更がなされた後に Apache を再起動します。

How To Enable File Caching

File caching は mod_file_cache モジュールにより提供されています。 この機能を使用するには、モジュールを有効にする必要があります。

Ubuntu 14.04 を実行している場合、このモジュールはインストールされますが、Apache をインストールすると無効化されます。

sudo a2enmod file_cache

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

sudo nano /etc/apache2/apache2.conf

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

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

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

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

実際には、同じファイル群に対して CacheFile と MMapFile の両方を設定する理由はないでしょうが、異なるファイル群に対して両方を使用することは可能でしょう。

sudo apachectl configtest

最終行が Syntax OK と書かれていれば、安全に Apache インスタンスを再起動できます。

sudo service apache2 restart

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

関連するサポート・モジュール。 mod_authn_socache, mod_ssl

主な使用例: SSL セッションまたは認証情報の保存、SSL ステープリング

特徴: 複雑なリソースを保存する共有オブジェクトキャッシュ、SSL セッションキャッシュとステープリングを支援できる、柔軟なバックエンド

欠点: SSL セッションキャッシュとステープリングに使用できる、SSL セッションキャッシュとステープルキャッシュに使用できる、SSL ステープリングとステープルキャッシュに使用できる、複雑なリソースのキャッシュとステープルキャッシュに使用できない。 より高性能で柔軟なバックエンドのために別のソフトウェアを構成する必要がある、コードにいくつかのバグがある

詳細

Key-value キャッシュはファイル キャッシュよりも複雑で、より集中した利点を持っています。 共有オブジェクトキャッシュとしても知られている Apache の Key-Value キャッシュは、コンテンツそのものではなく、 コンテンツへのクライアントのアクセスのセットアップに関わる高価な操作の繰り返しを 避けるために主に使用されます。 具体的には、認証の詳細、SSL セッションをキャッシュし、SSL ステープリングを提供するために使われます。

現在、すべての共有オブジェクトキャッシュプロバイダには、いくつかの問題点があります。 問題点への言及は以下に概説します。

実際のキャッシュは、共有オブジェクト キャッシュ プロバイダー モジュールの 1 つを使用することにより実現されます。 これらは、

• mod_socache_dbm: このバックエンドはシンプルな dbm データベース エンジンを使用し、ハッシュと固定サイズのバケットを使用する、ファイル ベースの key-value ストアです。
• mod_socache_dc: このプロバイダは、セッションキャッシングソフトウェアの distcache を使用しています。 このプロジェクトは 2004 年以来更新されておらず、いくつかのディストリビューションでは パッケージ化すらされていないため、使用には十分な注意が必要です。
• mod_socache_memcache: これは memcache 分散メモリオブジェクトキャッシュをアイテムの保存に使用します。 これは、複数のサーバで分散キャッシュを行うための最良の選択肢です。 現在、エントリを適切に期限切れにできませんが、Apache のバージョンコントロールの trunk にパッチがコミットされ、この問題が修正されました。 現在、これは key-value キャッシュのための最良の選択肢です。 これは共有メモリ内の周期的なバッファにキャッシュし、それが一杯になるとエントリを削除します。

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

How To Enable Key-Value Caching

上記のバグと注意点を念頭に置き、Apache でこのタイプのキャッシュを設定したい場合は、以下の手順に従ってください。 以下では、認証キャッシュと SSL セッション キャッシュの両方の基本について説明します。

現在、認証キャッシュには、キャッシュ プロバイダーに引数を渡せないというバグがあります。 そのため、デフォルトの設定を提供しないプロバイダーには問題があります。

認証キャッシュ

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

キャッシュを設定するには、既存の認証設定を変更します (このガイドでは、認証を設定する方法については説明しません)。 バックエンドの認証方法に関係なく、修正自体はほとんど同じです。

最初に、authn_socache モジュールと mod_socache_shmcb プロバイダー モジュールを有効にしてください。 プロバイダーとして shmcb が使用されるように指定します。 これを読むまでに、先に述べたオプション渡しを防ぐバグが修正されていれば、キャッシュの場所とサイズを指定することができます。 数字はバイト数なので、コメントした例は 512 キロバイトのキャッシュになります:

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でキャッシュタイムアウトを追加し、AuthBasicProviderのリストにsocacheを追加して従来の認証方法よりも前にする必要があります。 結果は次のようになります:

<VirtualHost *:80> . . . <Directory /var/www/html/private> AuthType Basic AuthName "Restricted Files" AuthBasicProvider socache file AuthUserFile /etc/apache2/.htpasswd AuthnCacheProvideFor file AuthnCacheTimeout 300 Require valid-user </Directory></VirtualHost>

上記の例はファイル認証用で、おそらくキャッシュによる利益はあまりないものと思われます。 しかし、他の認証方法を使用する場合、実装は非常に似ているはずです。 唯一の実質的な違いは、上記の例で “file” の指定がある場合、他の認証方法が代わりに使用されることです。

ファイルを保存して閉じます。

sudo service apache2 restart

SSL セッションキャッシュ

SSL 接続を確立するために実行されなければならないハンドシェイクは、かなりのオーバーヘッドを運びます。 そのため、さらなるリクエストのためのこの初期化ステップを回避するためにセッション データをキャッシュすると、このペナルティを回避できる可能性があります。

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

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

これだけで、セッション キャッシュを設定することができます。 これをテストするために、OpenSSL の接続クライアントを使用することができます。 Type:

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

すべての結果でセッションIDが同じであれば、セッションキャッシュは正しく動作しています。 CTRL-C キーを押してターミナルに戻ります。

Standard HTTP Caching

General Overview

• Primary modules involved: mod_cache
• 関連するサポートモジュール。 mod_cache_disk, mod_cache_socache
• 主なユースケース。 一般的なコンテンツのキャッシュ
• 機能。 HTTP キャッシュ ヘッダを正しく解釈できる、古いエントリを再検証できる、ニーズに合わせて最大速度または柔軟性のために展開できる
• 欠点。 不適切に設定された場合、機密データを漏洩する可能性がある、キャッシュ ポリシーを正しく設定するために追加モジュールを使用する必要がある

詳細

HTTP プロトコルは、コンテンツ配信パスのすべてのレスポンスをキャッシュするメカニズムを推奨し提供します。 コンテンツに触れるすべてのコンピュータは、コンテンツのオリジンで設定されたキャッシュポリシーとコンピュータ自身のキャッシュルールに応じて、潜在的に一定時間各アイテムをキャッシュできます。

Apache HTTP キャッシュ機構は、それが見る HTTP キャッシングポリシーに従って応答をキャッシュします。 これは、配信に手を貸す仲介サーバーが従うのと同じ規則に従う、汎用のキャッシュシステムです。 これにより、このシステムは非常に柔軟で強力になり、コンテンツにすでに設定されているはずのヘッダーを活用することができます (以下でその方法を説明します)。

Apache の HTTP キャッシュは、「3 状態」キャッシュとしても知られています。 これは、格納されたコンテンツが 3 つの状態のうちの 1 つであることができるためです。 コンテンツが古くなった場合、次のリクエストで、キャッシュはオリジンでコンテンツをチェックすることにより、コンテンツを再検証することができます。 変更されていない場合、新鮮な日付をリセットし、現在のコンテンツを提供することができます。 そうでない場合は、変更されたコンテンツを取得し、キャッシュ ポリシーで許可された期間、それを保存します。

モジュール概要

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

mod_cache_disk モジュールはディスク上にキャッシュするので、遠隔地からコンテンツをプロキシしている場合、動的プロセスからコンテンツを生成する場合、またはコンテンツが通常存在するよりも速いディスクにキャッシュして処理速度を上げようとする場合に有用でしょう。 これは最もよくテストされたプロバイダーであり、おそらくほとんどの場合、最初の選択肢となるはずです。 キャッシュは自動的に削除されないので、htcacheclean と呼ばれるツールを時々実行してキャッシュをスリム化する必要があります。

mod_cache_socache モジュールは共有オブジェクトプロバイダ (前のセクションで説明したものと同じもの) のひとつにキャッシュを行います。 これは (どの共有キャッシュプロバイダが選択されるかによりますが) mod_cache_disk よりも良いパフォーマンスを発揮する可能性があります。 しかし、これはより新しく、共有オブジェクトプロバイダに依存しており、先に説明したバグがあります。

HTTP キャッシュの配置

Apache の HTTP キャッシュは、ニーズに応じて 2 つの異なる構成で展開することが可能です。 コンテンツが見つかった場合、それ以上処理することなく直接提供されます。 これは、信じられないほど速いということですが、コンテンツに対する認証のような処理ができないということでもあります。 通常、認証やアクセス制御が必要なコンテンツがキャッシュ内にある場合、CacheQuickHandlerを「on」に設定すると、認証なしで誰でもアクセスできるようになります。

基本的に、これは Web サーバーの前にある別のキャッシュをエミュレートします。 もし、ウェブサーバが何らかの条件チェック、認証、認可を行う必要がある場合、 これは起こらないだろう。 Apache は <Location> や <Directory> ブロック内のディレクティブを評価することさえしません。 CacheQuickHandler はデフォルトで “on” に設定されていることに注意してください！

CacheQuickHandler が “off” に設定されている場合、キャッシュはリクエスト処理シーケンスのかなり後でチェックされることになります。 この設定は、Apache の処理ロジックと実際のコンテンツの間にキャッシュを置くと考えてください。 これにより、キャッシュからコンテンツを取得する前に、 従来の処理ディレクティブが実行されるようになります。 1051>

How To Configure Standard HTTP Caching

キャッシュを有効にするには、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

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

<IfModule mod_cache_disk.c> CacheRoot /var/cache/apache2/mod_cache_disk CacheDirLevels 2 CacheDirLength 1</IfModule>

IfModule ラッパーは Apache に mod_cache_disk モジュールが有効になった場合にのみこれらの指示を気にするように指示します。 CacheRoot ディレクティブはキャッシュを維持するディスク上の場所を指定します。 CacheDirLevels と CacheDirLength は、キャッシュのディレクトリ構造がどのように構築されるかを定義します。

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

CacheRootの値を変更することを選択した場合、/etc/default/apache2ファイルを開いてHTCACHECLEAN_PATHの値を変更し、その選択と一致させる必要があります。

このファイルで設定できる他のいくつかの値は、Apache がキャッシュにコミットするファイルサイズの範囲をバイト数で設定する CacheMaxFileSize と CacheMinFileSize 、クライアントに送信する前にコンテンツを待ったりバッファしたりする CacheReadSize と CacheReadTime があります。

Modifying the Virtual Server

Most of the configuration for caching will happen on the more granular level, either in the virtual host definition or in the specific location block.

Open one of your virtual host files to follow along.これは、コンテンツがこのサーバではないどこかに存在する場合に有用となる可能性がある、仮想ホストの定義です。 このガイドでは、デフォルトのファイルを使用していると仮定します。

sudo nano /etc/apache2/sites-enabled

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

また、この機会にキャッシュ ロックの設定も行います。 これは、Apache がコンテンツがまだ有効であるかどうかを確認するために、 コンテンツの発信元とチェックインするときに使用するファイルロックのシステムです。

検証中にリソースのキャッシュロックを設定することは、リソースが現在リフレッシュされていることを Apache に伝えます。 この間、古くなったリソースはその状態を示す警告ヘッダとともに提供されることができます。 /tmp フォルダにあるキャッシュロック用のディレクトリでこれを設定します。 ロックが有効であるとみなされるには、最大で 5 秒間かかるとします。

また、Set-Cookie ヘッダを無視し、キャッシュに保存しないように Apache に指示します。 そうすることで、Apache がユーザ固有のクッキーを偶然に他のパーティに漏らすのを防ぐことができます。

<VirtualHost *:80> ServerAdmin webmaster@localhost 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</VirtualHost>

このバーチャルホストに対して、実際にキャッシュを有効にする必要があります。 これは CacheEnable ディレクティブで行うことができます。 これがバーチャルホストブロックに設定されている場合、キャッシュ方法 (disk または socache) と、キャッシュされるべきリクエスト URI を指定する必要があります。 例えば、すべてのレスポンスをキャッシュするには、CacheEnable disk / と設定しますが、/public URI のレスポンスだけをキャッシュしたい場合は、CacheEnable disk /public.

特定のロケーションブロック内でキャッシュを有効にすることで、別のルートを取ることができます。 そうすることで、CacheEnable コマンドに URI パスを提供する必要がなくなります。 その場所から提供されるすべての URI は、キャッシュされます。

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

<VirtualHost *:80> ServerAdmin webmaster@localhost 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 <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 </Location></VirtualHost>

必要な設定をすべて行ったら、ファイルを保存して閉じてください。

sudo apachectl configtest

エラー報告がない場合、

sudo service apache2 restart

Setting Expires and Caching Headers on Content

上記の設定において、HTTP ヘッダーを使用した HTTP キャッシュを設定しました。 しかし、提供しているコンテンツには、インテリジェントなキャッシュ決定を行うために必要な Expires または Cache-Control ヘッダーが実際に存在するものはありません。

mod_expires モジュールは Expires ヘッダと Cache-Control ヘッダの max-age オプションの両方を設定することができます。

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

 
sudo a2enmod expires
 
sudo a2enmod headers
 

これらのモジュールを有効にした後、バーチャルホストファイルを再び修正することができます:

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

mod_expires モジュールは、わずか三つのディレクティブを提供します。 ExpiresActive は “on” に設定することで、特定のコンテキストで有効期限切れの処理を有効にする。 他の二つのディレクティブは互いに非常によく似ている。 ExpiresDefault ディレクティブはデフォルトの期限切れ時間を設定し、 ExpiresByType はコンテンツの MIME タイプに応じて期限切れ時間を設定する。 これらは両方とも Expires と Cache-Control “max-age” を正しい値に設定します。

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

ExpiresDefault A30ExpireByType text/html A30

他の構文では、より詳細な設定を行うことができます。 秒以外の人間にとって計算しやすい単位を使うことができます。 また、”access “または “modification “という完全な単語を使用します。 有効期限の設定全体は、次のように引用符で囲む必要があります:

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

今回の目的では、デフォルトの有効期限を設定するだけにします。 まずは5分に設定し、慣れてきた頃にミスをしたとしても、クライアントのコンピュータに極端に長い時間保存されることがないようにします。 コンテンツに適したポリシーを選択する能力に自信がついたら、これをより積極的なものに調整できます。

<VirtualHost *:80> ServerAdmin webmaster@localhost 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 <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" </Location></VirtualHost>

これにより、Expires ヘッダーを 5 分後に設定して Cache-Control max-age=300 を設定することができます。 キャッシュポリシーをさらに洗練させるために、Header ディレクティブを使用することができます。 merge オプションを使用して、さらに Cache-Control オプションを追加することができます。 これを複数回呼び出して、好きなように追加のポリシーを追加することができます。 このガイドを読んで、コンテンツに設定したいキャッシュポリシーについて考えてみてください。 この例では、他のキャッシュがコピーを保存することを許可されていることを確認できるように、「public」を設定します。

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

Apache が Etag を計算するために使用する属性を設定するために、 ディレクティブを使用します。 これは、ファイルの inode が変わったとき、修正時刻が変わったとき、サイズが変わったとき、 あるいは上記のすべてのときに ETag を変更したいかによって、 INode, MTime, Size, All のいずれかを指定します。 複数の値を指定することができ、新しい設定の前に+または-を付けることにより、子コンテキストで継承された設定を変更することができる。

<VirtualHost *:80> ServerAdmin webmaster@localhost 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 <Location /> 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 </Location></VirtualHost>

これにより、Cache-Control にすでにある値に “public” (カンマで区切る) を追加し、静的コンテンツ用に ETag を追加することになります。

sudo apachectl configtest

エラーが見つからなかった場合、キャッシュポリシーを実装するためにサービスを再起動します。 幸運なことに、単純なものから始めて、より複雑なものが必要なときに増やすことは簡単です。

キャッシュを設定するとき、異なる実装の選択肢で迷わないように、 解決しようとしている特定の問題を心に留めておいてください。 ほとんどのユーザーは、少なくともヘッダーを設定することで利益を得ることができます。 プロキシやコンテンツ生成を行っている場合は、HTTPキャッシュを設定することが有効かもしれません。 共有オブジェクトキャッシュは、バックエンドプロバイダを使用している場合、SSLセッションや認証の詳細を保存するような特定のタスクに便利です。 ファイル キャッシュは、おそらく低速のシステムで使用する場合に限定されます。