この記事の著者は、キャッシングの重要な段階に関する構造化された概要情報に会わなかったため、この分野での経験を共有し、この問題に関するすべての基本情報を組み合わせ、さらに各タイプのキャッシングの長所と短所を検討したいと思います。
まず、キャッシングがプロジェクトの最も重要なコンポーネントの1つであることを明確にしたいと思います。 特に、これは、限られたリソースを使用する場合に、より多く、より速く行う唯一の方法です。 そして、ご存知のように、リソースは常に制限されています。サーバーとユーザーの両方です。
キャッシングの主な問題は、着信および発信の構造化情報を保存および処理するためのメインシステムへの要求に対する応答速度です。
情報の迅速な転送を実行する必要があるが、データへのアクセス速度が非常に遅いと想像してください。 または、別の状況：速度は良好ですが、使用可能なメモリがほとんどないか、チャネル幅が不十分であるか、プロセッサとディスクの要因がタスクに干渉しています。 この場合、キャッシングが唯一の方法です。
キャッシングの種類
キャッシュ（またはキャッシュ）は、データが格納される中間バッファーです。 キャッシュのおかげで、サイトページはユーザーごとに再作成されません。 キャッシングを使用すると、限られたリソース（サーバーとユーザー）で、可能な限り短時間で大量のデータを処理できます。
データの処理は、クライアント側とサーバーの両方で実行できることを理解する必要があります。 さらに、サーバーのデータ処理は集中化されており、多くの明らかな利点があります（特にサポートサービスにとって）。
キャッシングにはいくつかのタイプがあります。各タイプ、その機能、および使用に関する推奨事項を検討することをお勧めします。
1.ブラウザキャッシュまたはクライアントキャッシュ
コマンドのブラウザが利用可能なキャッシュされたコピーを使用するためのコンパイルです。 このようなキャッシングの動作は、2回目のアクセス時に、ブラウザーにヘッダー304 Not Modifiedが与えられ、ページまたは画像自体がローカルユーザーキャッシュからロードされるという事実に基づいています。 訪問者のブラウザとホストしているサイト間のトラフィックを節約することがわかりました。 したがって、サイトのページの読み込みが速くなります。
1.1ファイルと画像のキャッシュ
ブラウザーのキャッシュは、多数の画像を含むサイトに最適です。画像は、サイトを開くたびにダウンロードされるのではなく、ブラウザーのキャッシュを介して単に読み込まれます。
これは、キャッシュの最初のレベルであり、 「期限切れ」ヘッダーと「304 Not Modified」ヘッダーを返すことで構成されます。 最も効果的なのは、2週間のキャッシュです。
ただし、この場合、重要なニュアンスがあります。サイトの画像が変更された場合、ブラウザはすぐにそれを認識せず、ブラウザ自体の有効期限を待つかキャッシュをリセットする場合のみです。 これは、ファイルが絶えず変化しており、常に現在のバージョンを提供する必要がある場合、あまり効果的ではありません。
1.2 httpsキャッシング
strict-securityという形式の特別なヘッダー。 ブラウザが選択したドメインへのhttpsに常にアクセスできるようにします。 この状態は非常に厳密に保存され、このタイプのキャッシュがキャンセルされると、ブラウザーは現在のヘッダーを無視して、かなり長い間httpsのページをロードしようとします。
1.3認証局のキャッシュ
いわゆる認証局のスタンプ。
サイトのユーザーが証明機関（およびこれが証明書の有効性を管理するサーバーである）がユーザーのブラウザーからの要求を処理し、それによってサイトが検証されたことを確認するのを待たない場合、このタイプのキャッシュは必須と見なされます。
1.4ページキャッシュ
ページが既に生成されている場合、その関連性を常に監視する必要があります。 これを行うには、サーバーキャッシュを使用して、ページの個々の部分の変更時間を追跡する必要があります（ページが多くの動的に生成されたブロックから構築されている場合）。 このアプローチでは、サーバーからの各応答には、ページが変更された時刻を示す特別なヘッダーがあり、サイトページに再度アクセスするとユーザーのブラウザーによって送信されます。 このようなヘッダーを受信すると、サーバーはページの現在の状態を分析できます（おそらくそれを描画することもできます）が、ページのコンテンツの代わりにヘッダー「304 Not Modified」を提供します。
もちろん、サーバー側のキャッシュトラッキングを使用せずに適切なヘッダーを送信できますが、この場合、ほとんどのユーザーはページコンテンツの更新をかなり遅れて受信します。 このアプローチでは、ブラウザがサーバーを更新のためにポーリングすることがありますが、各ブラウザーの頻度とルールは開発者によって設定されるため、ユーザーが時間通りに更新を受け取ることを期待する理由はありません。
通常、キャッシュはユーザータイプ別に細分化されます。
-承認済み。
-無許可。
この分離は、許可された各ユーザーのコンテンツとゲストユーザーのコンテンツコミュニティの一意性によるものです。 ほとんどのサイトでは、権限のないユーザーはサイトのコンテンツを変更できないため、コンテンツに影響を与えます。
ブラウザのキャッシュにより、ページの読み込みに費やされるトラフィックと時間が節約されます。 ただし、節約効果を得るには、ユーザーは少なくとも1回はページにアクセスする必要があります。つまり、サーバーリソースの負荷は減少しますが、大幅には減少しません。
2.サーバーのキャッシュ
サーバーキャッシュとは、データがサーバー側に保存されるすべての種類のキャッシュを指します。 このデータは、クライアントブラウザーでは使用できません。 キャッシュは1対多ベースで作成され、保存されます（この場合、多くはクライアントデバイスです）。
2.1ページ全体のキャッシュ
最も効果的なキャッシュ。 彼はどのように面白いですか？ その最大の利点は、ページがアクセス時にほぼ戻るということです。その結果、メモリ速度が低く、CPU使用量が少なく、最も弱いサーバー上でも数百万のリクエストを処理できます。
おそらく、誰もがping速度以上で動作するサイトを夢見たことがあるでしょう。
しかし、このタイプのキャッシュには欠点があります。たとえば、許可されたユーザー、または現在のユーザー変数に依存するページコンテンツを持つユーザーのページをキャッシュできないことです。
サーバーが外部データのすべての静的状態を知っている場合、このキャッシュを使用します：uri、get（追加パラメーターなし）、ユーザーは承認されていません-つまり、これはゲストユーザーにとって理想的なページ状態です。 このようなキャッシングでは、サイトまたはアプリケーションのアーキテクチャが常に同じ方法で着信要求を処理し、同じ回答を提供する必要があるという事実を考慮してください。 この状態はすべてのアプリケーションまたはサイトに存在し、追跡してキャッシュを適用するだけです。
ページキャッシュ全体は、いくつかの緊急事態で最もよく使用されますが、ページキャッシュは、サーバーからの応答が同じである所定の時間（2分から）保管されます（ブラウザーにこれをキャッシュさせないでください）。
2.2 PHPファイルのコンパイル結果のキャッシュ
コードの純粋なコンパイルとコンパイル時の最適化（スクリプトスプーフィング）を区別します。 最も顕著な例：
-APC ;
-XCache ;
-スクリプトHipHopVirtualMachineを置換したコンパイル。
プロジェクトでは両方のタイプのキャッシングを使用できますが、それぞれ独自の微妙な違いがあり、コードを記述するときに考慮する必要があります。
2.3個々のページブロックのキャッシュ
これはおそらく最も興味深いが、キャッシングの難しいタイプでもあります。 ただし、効果的な場合もあります。その例では、一般的なキャッシュの原則を説明するのが最も簡単です。
監視する必要があるのは、テーブルの状態、ユーザーセッションの状態、POSTまたはGETリクエスト（httpクエリ）中にキャッシュをオフにするかどうか、現在のアドレスへの依存、キャッシュの不変性（以前の条件が変更された場合）、またはその動的調整です。
たとえば、実際の（許可された）ユーザーからのデータベース要求の数を減らす必要がある場合、個々のページブロックのキャッシュは他の種類のキャッシュよりも優れています。 ちなみに、依存関係が正しく定義されていれば、後続のすべてのタイプのキャッシングよりもさらに効率的に機能します。
なぜこの種のキャッシュがそれほど重要なのですか？ 問題は、データベースサーバーのプールを拡張することは、サイトのphp部分のサーバープールを拡張するよりもはるかに複雑なタスクであるということです。 さらに、PHPキャッシュ状態の競合は、複数のデータベースを操作する場合の競合よりもはるかに簡単に解決されます。
2.4共有リソースに基づくPHPキャッシュ
クエリを標準化し、共有リソースからデータを取得し、ページを生成するときにphpリソースが数回アクセスする内部変数を持つのに最適です。
2.5共有リソースに基づいたPHPキャッシュ
このキャッシュを使用して、シリアル化されたデータを保存します。 例：構成ファイル、テーブル状態、ファイルシステムリスト。
2.6クエリキャッシュに基づくmysqlキャッシュ
これはかなりよく知られ、最も取り上げられているトピックです。 それでも、タイムスタンプの使用の詳細と、クエリキャッシュの永続的なリセットを回避する方法を検討したいと思います。
確かに、あなたは定期的に新しい資料を提出する必要がある状況に遭遇しました。その発行日は現在のタイムスタンプによってすでに許可されていますか？ 簡単に言えば
WHERE show_ts <= UNIX_TIMESTAMP（）
このようなクエリで絶えず変化するタイムスタンプを使用すると、キャッシュキャッシュは役に立たないだけでなく、キャッシュされたクエリの数が蓄積され、キャッシュ作成時にデータが古くなるため、有害ですらあります。
状況から次の方法を提供します。
原則として、資料は特定の時点で公開されます。 たとえば、00：00。 必要なことは、現在の日付よりも少ない日付でテーブルを評価するクエリを作成することだけです。
次のようなもの：
SELECT SQL_NO_CACHE MAX（show_ts）... WHERE show_ts <= UNIX_TIMESTAMP（）;
はい、このクエリはキャッシュされませんが、複数ある場合、このテーブルへのすべてのクエリはキャッシュされます。 この簡単な操作により、SQLキャッシングの寿命が大幅に向上します。
テーブルからの読み取り値が読み取り値よりわずかに大きい場合、これらのクエリをキャッシュすることは理にかなっています。
2.7 mysqlの結果のキャッシュ、集計テーブル
ルールがあります：それらを返すための読み取りよりも大幅に少ないデータ更新が必要です。
つまり、同時に変化したものを集約することは意味がありませんが、集約されたデータの関連性は重要です。
集約のために選択するものは？ 通常、これはレコードの数、最終更新の日付、最終更新の作成者などに関する何らかの統計情報です。
おわりに
キャッシングなしの一定のネットワーク負荷を考えると、単一のプロジェクトを作成することはできません。 キャッシングにより、最小限のリソースを使用しながら、幅広い顧客にデータを配信できます。 この記事では、多くのタイプのキャッシングを検討しましたが、その中にはプロジェクトに適したソリューションがあると確信しています。
