何をキャッシュしますか？

それだけです。 この公理はフォーラムや会議で年々繰り返され、すべての技術リソースに関するテキストからテキストへとさまよっているため、これで記事は終了する可能性があります。 ただし、この容量の多い「すべて」では詳細は説明されません。 結局のところ、かなり広い層のプログラマーがいて、そのエンジンとプロジェクトはミームやシャーディングなしでタスクに対処しています。 しかし、負荷の瞬間が来るので、それを把握する必要があります。

そのような人々のために、私はスペアパーツを分解しました。これは、負荷の高いプロジェクトの普遍的な答えです。

私たちは、ウェブ用のシステムの研究に専念しています。 簡単に言えば、おなじみの通常のサイトに。 既製のCMSを使用するか、 フレームワークに既に成長しているか、非標準プロジェクトの「ゼロから」コードを記述したかに関わらず、同じノードが常にデータ受信および受信プロセスの主要な要素になります。 「キャッシュできる場所」の観点からそれらを検討します。

データベース

ファイルデータベースがある場合でも、必要な情報を発行するのはドライバーです（そうではありませんか）。

ここには何がありますか？ 通常、アルファベット順にデータを整理するのは非効率的であるため、最高の頭脳は、銀の大皿で情報を迅速に配信するための膨大な数の方法、方法、およびハックをすでに思いついています。 また、データベースはインデックスを入力するだけでなく、それらをキャッシュし、クエリ結果をキャッシュし、リレーショナルテーブルの構造を最適化し、大量のデータを再度スキャンしないようにすることを知っておく必要があります。 しかし、天才への信仰は一つのことであり、これらのメカニズムが含まれているかどうか構成ファイルをチェックすることは、すべての開発者の義務です！ サーバー（または複数のサーバー）に個別の管理者がいる場合、最初に修正された単純な管理者に、最も重要なノードの設定のナットを締めさせます。 一時ファイルのメモリ消費、断片化、およびディスク容量の可用性を調べます。

タイムリーで有能なリクエストキャッシングは、急速に成長するプロジェクトのコンテキストで、後続のすべての段階でナットを締めるのに十分な時間を与えることができます。

この最適化は、ホスティングに完全にアクセスできるレガッタのすべての参加者が利用でき、遅かれ早かれトピックを把握する必要があります。

レプリカデータベースと呼ばれる別の豪華なフルフォーマットキャッシュがあります。 ただし、プロジェクトに既にマスターデータベース、そのレプリカ、Webサーバー、ファイルサーバー、統計情報収集グループなどの複雑な構造がある場合は、この記事を読むことはまずありません。 いずれの場合でも、独立した読み取りベースは、ストレッチ付きのキャッシュと見なすことができます。

ロジック（または私たちが誇りに思っているコード）

プログラミング言語は関係ありません。 これは、受信したデータを処理するための単なるツールです。 モジュラー構造がなく、プロジェクト全体が単一のファイルであっても、データを操作します。

コードの場合は、コードを書くときに頭を入れなければなりません。 急速な発展と聖なるORMに対する謝罪者は、探すべきものは何もないと言い、他の場所にキャッシュする方が良いと言います。 しかし、いくつかの真実があります、フリークが画家を生まないものは何ですか！

それで、すでにコードを見ているとき、私たちは何に注意を払うべきですか？

• データベースクエリを最適化します。 インデックスと日付だけが必要なときにすべてのデータをプルするのはなぜですか？ クエリが小さいほど、データベースでのキャッシュが容易になります。
• データベースユーティリティを使用して、いわゆるスロークエリを定義します。 テーブル内のインデックスまたはクエリと必要なデータの再スケジュールのインデックスについて考えてください。これはキャッシュには適用されませんが、ここにいるので 、今はそうではないでしょうか？
• コードを安定させた後、同じまたは類似のデータについて、データベースにアクセスする場所を2回調べます。 1つのリクエストをより厚くする方が良いかもしれませんが、その後、受信したデータをいくつかのモジュール/機能/ループで使用しますか？ これはまだキャッシュされていませんが、さらなる最適化-複雑なまたは大規模な計算結果をシリアル化された配列としてキャッシュに（データベースまたはファイルに）取得するか、あなたにとって便利なものは非常に便利です。 そして、中間計算は、サイト、スケジュールされたタスク、およびAPIにとってより高速で、低コストで、より快適になります。
• セッションで、変数で、Cookieで単一の場所（セキュリティポリシーで許可されている場合）に通常ハングするすべてのささいなものを収集し、そのようなノートブックを参照します。 これは、ファイルシステムを呼び出して、一般クラスの関数を呼び出すクラスメソッドを呼び出して、ユーザーにログインを提供するか、恐ろしいことに単純な要求でデータベースをプルするよりも優れています。 結局のところ、セッションの読み取りは、セッションファイルからではなくRAMからのものであると確信していませんか？ または、需要のない管理者がデータベースでセッションを作成し、メソッドがそれを考慮しなかった可能性がありますか？ または、コードのロジックには、大量の抽象化とサブ関数呼び出しによる国際化が含まれており、「Basket」という単語をajaxで3回返す必要があります。

最後にコードを処理することをお勧めします。 つまり、ビジネスが確立され、ベースが最適化され、外部キャッシュが機能し、すべてが正常に機能し、拡大しています。 このノードでのデータのキャッシュは、サーバー側の拡張コストを最適化する段階、または狭い数学的部分に大きなデータストリームを処理する時間がない場合に行う必要があります。 これは、ネットワーク企業の面倒なマーケティング計画で発生し、空想的な統計などのレポートを生成します。 最適化の結果は、あまり負荷がかかっていないサーバーの負荷が減少するだけで、バランサーと2番目のサーバーの購入時間が遅れます。

まだCMSに座って最適化について考え始めている場合は、負荷の高いニーズに合わせてエンジンを書き直したり、RAMを購入したりします。 お金がない その後、リソースの収益化に早急に取り組み、コードの腸を拾わないでください！

テンプレートエンジン

コードのようですが、もう少し専門的です。 この要素はほとんど常に存在し、私たちの研究にとっても重要です。

テンプレートとは何ですか？ これは、後続のコンパイル用のコードを作成するための原料として機能する一種の構造です。 唯一の違いは、このコードでは、ロジックの断片が散在する膨大な数のタグ、行、およびリンクです。 そのことは非常に理解しやすいことですが、多くの初心者はスマートで電撃的な仕事の詳細を掘り下げていないことに気付きました。 しかし、無駄に！

失礼な場合。 次に、テンプレートエンジンは、以前にコンパイルされたコードを最初に検索します（またはその関連性をチェックします）。 そうでない場合、テンプレートを再処理し、ファイルを書き込みます（以前のファイルを削除することもあります）。 時々、開発者は単にそのようなテンプレートのキャッシュを有効にすることを忘れます（作業バージョンではキャッシュをクリアするのは不便です）。 オプションがオンになっている場合はさらに悪いが、プリコンパイルされたファイルの寿命は短い。 その場合、遅延は不規則であり、初心者にとって「キャッチ」することは困難です。 症候群「スローダウンしません」。

テンプレートエンジンのキャッシュ機能を理解し、最適な更新間隔を選択します（必要な場合）。 極端な場合は、夜間にこのキャッシュを強制的に更新するスケジュールにタスクを入れて、ピーク時に出ないようにします。 キャッシュが保存されているディスクの速度特性を調べます。 多分それは理にかなっており、RAMで作る機会がありますか？

この段階のキャッシングの構成は、プロジェクトの開発の開始時に必須です。 ただし、最適な値の列挙は、ベースを調整して発行キャッシュを導入した後、すでに転送できます。

完成したCMSに座っている人にとっては、想像する余地はあまりありません。 ただし、使用されているもの（アルゴリズムまたは完成品）を確認し、テンプレートキャッシュの保存場所と動作を確認することは不要です。

結果

generated下生成されたページは、必要な関連性を備えて、できるだけ早くクライアントに配信される必要があります。 ここで、ファイルキャッシュやお気に入りのmemekeshなど、個別に何かを考え出すことができます。

興味を持ってこの記事をまだ読んでいる場合は、おそらくプロジェクトでブレーキングの問題がすでに発生している可能性がありますが、通常どおり正常に動作しています。

プロジェクトの実装とサイト構築のaksakalsについては、memkeshクラスターの設定に新しいものはなく、その問題は選択の関連性にかかっています。 しかし、驚いたことに、通常サイズの膨大な数のプロジェクトがあります。Webマスターの手は、noSQLデータベースの通常の通常のキャッシュにまだ到達していません。 最初、彼らはできる限り最善の形でプロジェクトを提起し、その場でアイデアを形成しました。 それから、2番目のサーバーに十分なお金が足りない可能性があります。そこでは、ふかふかのデータベースを取り出す価値があります。 ビジネス、デザイン、優れたテキストの作成に精通している人は非常に多くいます。 彼らはプロジェクトを提起しましたが、彼らはmemekeshをインストールするために* nixの管理に深く入ります。

つまり、おむつが大きくなった場合、最初に行うことは、テンプレートエンジンの後に準備ができているページをキャッシュすることです。 最初の静的。 次に、動的ページの静的フラグメント。 次に、ボトルネックを探します。 Key-Valueストレージをインストールする権限がない場合は、最初に最も要求の多いページのファイルキャッシュを作成します。 そのような原始的なものでさえ、以前のノードでの数か月以上の最適化を節約します。

コンテンツ管理システムのユーザーは、ご使用のバージョンのキャッシュモジュールのビンを確認する必要があります。 または彼の最も成功したオプション。 たとえば、MODxには、ページ全体だけでなく、個々のチャンクとスニペットのファイルキャッシュメカニズムがすぐに含まれます。 ただし、ファイルストレージの代わりにmemekeshの使用を提案するモジュールがあります。

バランサー

まだお持ちでない場合は、時間が経つにつれて表示されます。 その外観では、上からのがらくた全体がバックエンドと呼ばれ、サブタイトルがフロントエンドと呼ばれます。 公平に言うと、結果のファイルキャッシングとアーキテクトの癖によるフロントエンドは、並べて、逆の順序で配置できると言わなければなりません。 しかし、初心者向けの単純な記事の分類を複雑にしないでください。

バランサーのタスクは、すべてのバックエンド間で通常のリクエストのキューを開くこと、リクエストのタイプによって送信先を決定することなどです。 この段階での主な最適化は、ロジックとデータベースを使用してWebサーバーからのすべての重いバリケードをバイパスし、静的要素を返すことです。 これらは主に写真、スタイルシート、ドキュメントです。 ファイルキャッシュを個別に構成できます。これは、バックエンドではなく、バランサーによって直接返されます。 html（js、css、xml）ページの配信を適切な方法でタイムリーに編成することのみが必要です。

バックエンドの結果をキャッシュするためのパーソナライズされたロジックを持つ独自のモジュールを作成できます。 結局のところ、答えは必ずしもキロメガバイトではありません。 バランサーサーバーのメモリ内のすべてのユーザーに対して、現在の最高のプレーヤーまたは最後の管理者のツイートでJSONを記憶することができます。

プロジェクトの初期段階でバランサーの実装に頼ることができます。 Engenixは、Apacheの前に食べる量が少なく、プロジェクトのスケーラビリティが向上します。

お客様

彼もまた、何かを覚えており、システムのすべての悪魔を苦しめることをもう一度求めないように私たちの説得にさらされています。 また、ブラウザ自体は、リモートサーバーを不必要な苦痛から救おうとしています。 グラフィックファイルおよびその他のマルチメディアはローカルにキャッシュされます。 ログインとパスワードのペア、最後にアクセスしたリソースなどを覚えておいてください。 しかし、さらに高度なオプションを作成することもできます。結局、私たちはページから何を望むかを知っています！

最小バージョンでは、パーソナライズされたささいなものをCookieに保存することができます。 フラッシュにはオーバークロックするための数メガバイトがあります。 HTML5は、巨大なTalmud形式でメモを保存するためのさらに大きなテストの場を提供します。 クライアント側で安全な情報を保持し、javascriptを使用してページを変更します。 カート、最近送信されたメッセージ、現在の弾薬など。

さらに良いのは、アプリケーションのロジックを通常のPHPから切り離して、それを最愛のユーザーの側に転送するときです。 スクリプト自体はブラウザーによってキャッシュされ（事前にangenicsによって弾丸に与えられます）、サーバー側では静かにローカルキャッシュから個人データ（購入、ボーナス、殺されたモンスター）の統計を計算します。

要約する

技術者ではなく、すべてのビジネススタートアップに、タイトルのフレーズと短い答えが、問題を解決するためにお金を払うだけでなく、はるかに多くのものになることを願っています。 通常のWebプロジェクトの一般的なスキームを、ユーザーに単一の応答を与えるという観点から検討し、キャッシュを使用して最適化できる内容とタイミングと方向を理解しました。 プログラマーにコードの最適化を促す前に、RAMの購入やバランサーとミームを備えた新しいサーバーの導入の効果を安全に分析できます。

キャッシュする方法と正確に別の問題です。 どこで、いつ、あなたはすでに決定できると思います：

1. データベース構成で基本的なささいな設定をすばやく設定し、テンプレートエンジンとCMSのキャッシュを確認します。 可能であれば、すぐにバランサーを構成し、Webサーバーをバイパスして静的のリターンを整理します。
2. 結果（静的、動的フラグメント、フルキャッシュ）をファイルまたはキーと値のストレージにキャッシュします。
3. データベースを深く研究し、最も効率的なクエリキャッシングを構成し、キーを最適化します。 たぶん、レプリカを導入する時です。
4. テンプレートエンジンの内部を調査し、パラメーターを最適化します。 おそらく、おなじみのSmartyを、より高速だが実装が難しいBlitzに変更しているのでしょう。 このレベルでファイル操作を削減および高速化します。
5. わずらわしいコードや過剰なコードを排除します。 データベースのデータを使用して作業を最適化し、小さなことで作業を整理します。
6. 作業コードとプロジェクトの実証済みのビジネスロジックで、日常的な操作、個人用設定、およびその処理をクライアント側に転送し始めます。

プロジェクトを最適化するための唯一の方法はキャッシングだけではないことを忘れないでください！