キャッシング

提供:MoodleDocs
2019年7月11日 (木) 15:03時点におけるMitsuhiro Yoshida (トーク | 投稿記録)による版 (→‎Memcached)
移動先:案内検索


作成中です - Mitsuhiro Yoshida (トーク)

キャッシュは負荷の高いデータベースクエリを避けて再利用するため手元に置かれる一群の処理済みデータです。

Moodle 2.4にはMUC (Moodle Universal Cache) が実装されました。この新しいシステムによりMoodleの特定の機能 (例 ストリング取得) で異なるインストール済みキャッシュサービスを利用することができます (例 files、ram、memcached)。

私達は将来的なMoodleのバージョンでも継続してMUCを使用する機能を拡張します。これによりパフォーマンスが改善されますが、あなたのサイトを今からパフォーマンス改善することができます。

パフォーマンステストに関する一般的なアプローチ

以下、あなたが取るべき一般的な戦略です:

  1. あなたの実運用インスタンスに可能な限り近いテスト環境を構築してください (例 ハードウェア、ソフトウェア、ネットワーク等)
  2. この環境から可能な限り多くの管理外の変数を削除するようにしてください (例 他のサービス)。
  3. あなたのサーバでシミュレーションおよび繰り返し処理を実行できて、実際の動作も再現できるツールを使用してください (例 jmeterまたはselenium)。
  4. データ (Ram、ロード、所要時間等) を取得してサーバのパフォーマンスを計測する方法を決定してください。
  5. あなたのテスト環境を実行してベースラインパフォーマンス結果を計測してください。
  6. 同時に変数を変更してパフォーマンスが良くなるか悪くなるか確認するためテスト環境を再度実行してください。必要に応じて処理を繰り返してください。
  7. 継続的なパフォーマンスの改善をもたらす設定を探り当てた場合、あなたの実運用サイトに適用してください。

Moodleのキャッシュ設定

Moodle 2.4以降、Moodleはキャッシュデータを保存する場所を管理者がコントロールできるキャッシングプラグインフレームワークを導入しました。ほとんどのMoodleサイトではデフォルトの設定が適切であり、設定変更する必要はありません。規模の大きなMoodleサイトでは管理者はmemcached、mongodbまたはキャッシュデータを保存するためのその他のシステムを使用したいと考えるでしょう。管理者はキャッシュ管理画面でどのキャッシュをどこに保存するか設定することができます。
Moodle内のキャッシングはMoodleユニバーサルキャッシュ (Moodle Universal Cache) によってコントロールされます。これは一般的にMUCと呼ばれます。

このドキュメントではMUCの概念および設定オプションに関する詳細に入る前にMUCとは何であるのか簡潔に説明します。

Moodleにおける基本的なキャッシュの概念

Moodleのキャッシングは概観と同じく難しいものではありません。背景の知識を少しだけ学ぶことにより、キャッシュ設定に関して多くを理解することができます。

キャッシュタイプ

キャッシュタイプ (時々、モードと呼ばれます) から始めましょう。Moodleには3つの基本的なキャッシュタイプがあります。

最初はアプリケーションキャッシュです。これは現在のところコードで最も一般的に使用されているキャッシュタイプです。この情報はすべてのユーザで共有された上でデータはリクエスト間で保持されます。ここでキャッシュされる情報には通常1または2つの理由があります。その理由は主要なリクエストに必要な情報を私たちのデータベースリクエストのために保存するため、またはアクセス頻度が低いのに関わらず取得に資源への負荷がかかる情報を保存するためです。
この情報はデフォルトであなたのMoodleデータディレクトリ内の組織化された構造に保存されます。

2番目のキャッシュタイプはセッションキャッシュです。これはあなたがすでに知っているPHPセッションに似ています。実際のところ、デフォルトでPHPセッションを使用しています。あなたはなぜ私たちがこのキャッシュタイプを持っているのか不思議に思うかもしれませんが、答えはシンプルです。MUCは保存のための管理手段を提供た上でリクエスト間で必要な情報を削除します。これは開発者に車輪を再発明せずに使用できるフレームワークを提供して私たちに必要なキャッシュを管理する手段があることを保証します。
デフォルトではセッションキャッシュはPHPセッションに保存されPHPセッションはデータベースで保存されるため、これは頻繁に使用されるキャッシュタイプではないことに留意してください。私たちはセッションを肥大させたくないため、またデータベース負荷をかけたくないため、セッションキャッシュタイプの使用は小さなデータセットに制限しています。

3番目、そして最後のキャッシュタイプはリクエストキャッシュです。このキャッシュタイプに保存されたデータはリクエストの存続時間のみ存続します。あなたがPHP開発者の場合、このキャッシュタイプを管理静的変数のように考えてください。
これは3つのキャッシュタイプの中でも一番使用されるキャッシュタイプです。ほとんどの場合、このキャッシュタイプの使用は同じリクエストの中で数回アクセスされる情報に制限されますが、通常はコードの範囲を超えます。 キャッシュされた情報はデフォルトでメモリに保存されます。

キャッシュタイプおよび複数サーバシステム

あなたのシステムが複数フロントエンドのウェブサーバの場合、アプリケーションキャッシュをサーバ間で共有してください。言い換えれば、あなたは速いローカルストレージをアプリケーションキャッシュに使用することはできません。共有ストレージまたは共有memcacheのような形の共有キャッシュを使用してください。

あなたが「スティッキーセッション」メカニズムを使用してユーザが常に同じフロントエンドサーバにアクセスすることを確実にしない限り、セッションキャッシュにも同じ内容が適用されます。

キャッシュバックエンド

キャッシュバックエンドは実際にデータが保存される場所です。これにはファイルシステム、phpセッション、Memcachedおよびメモリのようなものを含みます。
デフォルトではMoodle内でファイルシステム、phpセッションおよびメモリが使用されます。
私たちはMemcachedのような他のシステムによるサイトへのアクセスを必要としません。代わりにあなた自身の責任で何か他のものをインストールおよび設定してください。
キャッシュのバックエンドが言及された場合、データの保存に使用されているMoodle外部のシステムのことを考えてください。MongoDBサーバ、Memcacheサーバおよび類似の「サーバ」アプリケーション。

キャッシュストア

キャッシュストアはMoodleのプラグインタイプです。これは前述のキャッシュバックエンドとMoodleの接続をサポートします。標準的なMoodleには前述のMemcache、Memcached、MongoDB、APCユーザキャッシュ (APCu)およびRedisに加えて3つのデフォルトがあります

あなたは他のキャッシュストアプラグインをプラグインデータベースで探すことができます。

これらのコードはあなたのMoodleのルートディレクトリ内cache/storesにあります。

あなたのアーキテクチャに必要とするだけのキャッシュストアを設定することができます。いくつかのMemcacheサーバがある場合、あなたはそれぞれにキャッシュストアインスタンスを作成することができます。あなたが他に設定しない場合に使用されるキャッシュストアインスタンスがMoodleにはデフォルトで3種類あります。

  • すべてのアプリケーションキャッシュとして使用するためファイルストアインスタンスが作成されます。ファイルストアインスタンスはあなたのmoodledataディレクトリにデータを保存します。
  • セッションストアインスタンスはすべてのセッションキャッシュに使用するため作成されます。
  • スタティックメモリストアインスタンスはすべてのリクエストキャッシュタイプに使用するため作成されます。メモリ内のデータはリクエストの存続期間のみ存在します。

キャッシュ: コード内では何が起きているのか

キャッシュはコード内で作成され、開発者が確認する必要のあるデータを保存するため使用されます。
恐らく、あなたは開発者ではないでしょうから、このセクションで分かりやすく簡単に説明してみましょう。あなたが知るべき非常に重要なことが1点あります。

開発者はデータがどこにキャッシュされるかに関して知ることはありません。使用するキャッシュを作成する場合、開発者は以下の情報を指定する必要があります。

  1. 必要なキャッシュタイプ
  2. このキャッシュが属するコードのエリア (あなたがAPIを使用する場合はAPI)
  3. キャッシュ名 (キャッシュが何に使われるのか表した単語)

いくつかの指定できる任意の必須条件および設定もありますが、現時点では心配しないでください。
重要な点は使用するキャッシュバックエンドを開発者は選択できないこと、また前述の3つのタイプから必要なキャッシュタイプを選択できるのみであることです。

どのようにして繋ぎ合せるのか

以下、組織内でのロールに関して説明します。

  1. システム管理者はあなたが使用したいMemcache、XCache、APCのようなキャッシュバックエンドをインストールします。
    Moodleはこれらに関して知りません。これらはMoodleの範囲外であり、純粋にあなたのシステム管理者に責任があります。
  2. それぞれのバックエンドがサイトで利用できるようMoodle管理者がキャッシュストアインスタンスを作成します。
    それぞれのバックエンドには1つまたはそれ以上のキャッシュストアを置くことができます。Memcachedのようなバックエンドには1つのバックエンド内に複数の別々のスペースを作成できる設定があります。
  3. 開発者はコード内でキャッシュを作成して、それをデータ保存のために使用します。
    開発者はあなたがキャッシュをどのように使用するか知りません。開発者はキャッシュを作成して、最適なキャッシュタイプをMoodleに伝えるのみです。
  4. Moodle管理者はキャッシュストアとキャッシュ間のマッピングを作成します。
    そのマッピングは開発者がキャッシュしたいデータを保存するため、あなたが指定したバックエンドを使用するようMoodleに伝えます。

加えて、あなたはさらに以下のことができます。

  • あなたは多くのキャッシュを単一のキャッシュストアインスタンスにマッピングすることができます。
  • あなたは複数のキャッシュストアインスタンスを単一のキャッシュに優先度 (最初... 最後) を付けてマッピングすることができます。
  • あなたは特定のマッピングを持たないタイプのキャッシュすべてに使用されるデフォルトストアとしてキャッシュストアインスタンスをマッピングすることができます。

これがあなたにとってMoodleユニバーサルキャッシュに関して資料を読むことが最初である場合、非常に複雑に思えるかもしれませんが心配しないでください。私たちはMoodle内でのキャッシング設定に取り組むため、Moodleユニバーサルキャッシュの詳細に関して取り上げます。

高度な概念

これらの概念は多くのサイトでは知る必要のない、または関わる必要のないものです。

あなたが共有バックエンドを持つクラスタサーバで規模の大きなサイトを運用している場合、またはサイト間で情報が共有されている複数サイトアーキテクチャでサイトを運用中でありパフォーマンスを最大にする方法を探している場合のみ、ここからお読みください。

ロッキング

ロッキングのアイデアに新しいものは何もありません。ロッキングは並列問題を避けるためアクセスをコントロールする処理です。

MUCは2つ目のタイプのプラグインであり、ロックが必要な場合に使用されるキャッシュロックプラグインです。今までキャッシュを必要としませんでした。元来、キャッシュは不安定なものであり、極めて重要なデータはデータベースのような永続的なデータストアに保存すべきです。

それにもかかわらず、オプション内でキャッシュ定義を要求してキャッシュストアインスタンスとの通信時に適用されるロッキングシステムがあります。

共有

キャッシュ内に保存されるデータすべてのビットには関連付けられるよう計算されたユニークキーがあります。
デフォルトではキーの一部はサイト特有のキャッシュにコンテンツを保存する際のサイトIDです。ほとんどのサイトでは正にあなたが必要としているものです。
しかし、いくつかの場面では複数サイトを許可したり、キャッシュデータを共有するために何らかの形でサイトをリンクすることは有益です。
もちろん、すべてのキャッシュを共有できるということではありません。しかし、共有することで負荷を減らして使用できるリソースを増やすことにより、確実にパフォーマンスを改善できる場合があります。

これは高度な機能であり、あなたが共有を選択する場合は注意して設定してください。

共有を使用する場合、あなたは最初に情報を共有したいサイトのキャッシュストアインスタンスを同一に設定する必要があります。それぞれのサイトでキャッシュの共有を同一の設定値に設定してください。

同じサイトIDのサイト
これはデフォルトです。キャッシュ情報を共有するため同じサイトIDのサイトが許可されます。これは最も制限のあるものですがすべてのキャッシュで動作します。他のオプションにはリスク要因があるため、アクセス可能なサイトすべてにおいてキャッシュ情報を利用できることを確実にしてください。
同じバージョンで動作しているサイト
バックエンドにアクセスする同じバージョンのMoodleサイトすべてはキャッシュストアに保存されたキャッシュ情報を共有することができます。
カスタムキー
あなたはここに共有に使用するキーを手動で入力することができます。あなたが情報を共有したい他のサイトに全く同じキーを入力してください。
誰でも
キャッシュ済みデータにはデータにアクセスできる他のサイトすべてからアクセスすることができます。このオプションでは一連のMoodle管理者にすべての権限を与えます。

例えばAPCがインストールされているサーバで同じバージョンの複数のMoodleが動作している場合、あなたは言語キャッシュをAPCストアにマップして同じバージョンが動作しているサイトすべてに共有を設定することができます。
同じバージョンのサイトの言語キャッシュの共有は多くの場合において安全です。APCは極めて速く、言語キャッシュは実際にはすべてのページで使用されます。これら3点はあなたのサイトのパフォーマンスを大幅に上げることでしょう。
言語キャッシュを考慮することは大切です。すべての言語のキャッシュをサイト間で共有した場合、独自に修正した部分も共有されます。

キャッシュ設定画面

あなたはキャッシュ設定でMoodleのキャッシングに関するすべてを設定することができます。
ここではあなたのサイトの現在の設定がどのようにされているのか概要を示します。また、あなたの必要に応じて設定するための操作のリンクすべてが提供されます。

キャッシュ設定画面にアクセスする

ファイル:cacheadmin29.png
キャッシュ設定画面

キャッシュ設定画面には「moodle/site:config」ケイパビリティのあるユーザのみアクセスすることができます。これはデフォルトではサイト管理者のみです。
設定画面はログイン後の「管理 > プラグイン > キャッシング > 設定」にあります。

キャッシュストアをインストールする

ファイル:ist29.png
インストール済みキャッシュストアスクリーンショット

ここではあなたがインストールしたキャッシュストアプラグインを一覧表示しています。
あなたはそれぞれのプラグインを使用できるかどうか (すべてのPHP要件に合致しているか)、このサイトですでにいくつのストアインスタンスが存在するか、このストアが使用できるキャッシュタイプ、サポートされる (高度な) 機能およびこのストアに関連して実行できる操作を素早く確認することができます。

ほとんどの場合、可能な操作は新しいストアインスタンスを作成するのみです。
ほとんどのストアは複数インスタンスをサポートしますが、すべてではありません。例えばセッションキャッシュおよび静的リクエストキャッシュは複数インスタンスをサポートしません。これら2つのストアに関しては複数インスタンスを持つことに意味はありません。

設定済みストアインスタンス

ファイル:csi29.png
設定済みストアインスタンスのスクリーンショット

以下、このサイトであなたが取得できるキャッシュストアの一覧です。

ストア名
このキャッシュストアの作成時にあなたが識別するためにつけた名称です。あなたが好きな名称を使うことができます。また、あなたがストアインスタンスを識別するためだけに使用されます。
プラグイン
このインスタンスのキャッシュストアプラグインです。
準備完了
接続またはセットアップ要件が確認されると共にPHP要件が合致した場合にチェックマークが表示されます。
ストアマッピング
このストアインスタンスに明確にマッピングされたキャッシュ数です。デフォルトマッピングの使用は含みません (以下で取り上げます)。
モード
このキャッシュインスタンスが提供できるモードです。
サポート
このキャッシュストアインスタンスでサポートされている機能です。
ロッキング
ロッキングはデータが上書きされないようキャッシュデータへのアクセスを1度に1プロセスのみに制限するためのメカニズムです。ロッキングメソッドはロックの取得および確認方法を決定します。
操作
このキャッシュストアに対して実行することのできるすべての操作です。

既知のキャッシュ定義

ファイル:caching-27-04-known-cache-definitions.png
既知のキャッシュ定義スクリーンショット

ここではキャッシュ定義のアイデアはまだ考察されていません。これは管理者によって管理されるものです。開発者がキャッシュを作成する場合、2つの方法があります。最初の方法ではキャッシュ定義を作成します。これは基本的にどのようなキャッシュを作成したのかMoodleに伝えます。2番目の方法はアドホック (Adhoc 限定目的) のキャッシュを作成することです。開発者は常に最初の方法を取ることをお勧めします。定義のあるキャッシュのみマップできます。また、定義のあるキャッシュのみさらに管理者が設定できます。アドホックキャッシュはデフォルト設定のみ使用します。
通常、アドホックキャッシュはキャッシュが小さい場合のみ許可されます。アドホックキャッシュのサイズがデフォルトより大きくなった場合、管理者に利点はありません。これは管理者にあなたのキャッシュに関わらないでくださいと言っているようなものです。

あなたはここで表示されているキャッシュから以下の情報を取得することができます:

定義
キャッシュに関する簡単な説明です。
モード
このキャッシュのキャッシュタイプです。
コンポーネント
キャッシュが割り当てられるコードコンポーネントです。
エリア
このキャッシュがコンポーネント内で提供されるコードのエリアです。
ストアマッピング
このキャッシュに使用されるストアです。
共有
このサイトの共有設定です。
操作
このキャッシュで実行されるすべての操作です。一般的にあなたはキャッシュストアを編集、共有を編集、キャッシュを削除できます。

あなたにはこのテーブルの最下部に「定義を再スキャンする」リンクが表示されます。このリンクをクリックすることにより、Moodleがすべてのコンポーネントおよびインストール済みプラグインをチェックしてキャッシュ定義の変更点を探します。しかし、あなたがそこにないキャッシュを探すのでしたら、試してみる価値はあります。

また、開発者がキャッシュで作業する場合、変更点をすぐに提供できる点も便利です。キャッシュ定義を調整する時にどの設定が最良であるか探す場合も便利です。

特定のキャッシュ定義に関する情報はキャッシュ定義ページをご覧ください。

キャッシュロックインスタンス概要

ファイル:caching-27-05-summary-of-cache-lock-instances.png
キャッシュロックインスタンス概要のスクリーンショット

上で言及したようにキャッシュロッキングはMUCの高度な概念です。
ここでテーブルはMUCで利用可能なロッキングメカニズムの設定情報を表示します。デフォルトでは次の単一のロッキングメカニズムのみ利用できます: ファイルロッキング 現在、これを使用しているキャッシュは存在しないため、これ以上ここで説明しません。

マッピングが存在しない場合に使用するストア

ファイル:caching-27-06-stores-used-when-no-mapping-is-present.png
デフォルトストアマッピングのスクリーンショット

このテーブルでは適当なマッピングが存在しない場合にどのキャッシュストアインスタンスが使用されるか簡単に示しています。
これをシンプルにするため、ここではそれぞれのタイプのデフォルトのキャッシュストアを表示します。

最後に「マッピングを編集する」ボタンがあります。あなたはこれによりマッピングを設定するページに移動できます。

キャッシュストアインスタンスを追加する

デフォルト設定はすべてのサイトで動作します。しかし、あなたのサイトのパフォーマンスを多様なキャッシュバックエンドおよび技術により改善することができます。あなたが取り組みたい最初のことはセットアップしたキャッシュバックエンドに接続するため設定されたキャッシュストアインスタンスを追加することでしょう。

ファイルキャッシュ

ファイル:caching-27-07-add-file-cache-store.png
ファイルキャッシュストア追加のスクリーンショット

あなたには「インストール済みキャッシュストア」テーブルでファイルキャッシュプラグインが表示されます。「インスタンスを追加する」をクリックしてファイルキャッシュストアインスタンスの追加処理を開始してください。

ファイルキャッシュを作成する場合、実際のところ、必須パラメータはストア名1つのみです。ストア名は設定インターフェースでファイルストアインスタンスを認識するために使用されます。ストア名はサイト内でユニークである必要があります。 あなたが好きなストア名にすることができますが、ファイルストアの使用目的を意図した名称にすることをお勧めします。

ファイルキャッシュの場所および使用目的に関して次のプロパティも指定およびカスタマイズすることができます。

キャッシュパス
あなたはファイルシステムへのキャッシュデータ保存時に使用するディレクトリを指定できます。もちろん、ウェブサーバのユーザにはこのディレクトリへの読み書き権が必要です。デフォルト (空白) ではMoodleデータディレクトリが使用されます。
自動ディレクトリ作成
この設定を有効にした場合、キャッシュ作成時に指定されたディレクトリが存在しない場合にMoodleは自動的にディレクトリを作成します。ディレクトリが指定されて存在しない場合、キャッシュは準備できていないと見なされ使用されません。
単一ディレクトリストア
デフォルトではファイルストアはデータを保存するためサブディレクトリ構造を作成します。データキーの最初の3文字はディレクトリ名に使用されます。これはディレクトリあたりの最大ファイル数を持つファイルシステムの制限を回避するため有用です。このオプションを有効にした場合、ファイルキャッシュはデータの保存にサブディレクトリを使用しません。これによりフラットな構造になりますが、ファイルシステムの制限に達する可能性があります。使用には注意してください。
ディレクトリを事前スキャンする
ファイルキャッシュが提供する機能の1つにキャッシュ初回使用時のストレージディレクトリの事前スキャンがあります。これにより詳細な読み込みを犠牲にすることでファイルを素早くチェックできます。

ファイルキャッシュストアはアプリケーションキャッシュに使用されるデフォルトのストアです。また、デフォルトではmoodledataディレクトリがキャッシュに使用されます。 サーバ負荷が増えた場合、ファイルアクセスに負担がかかる場合があります。以下、パフォーマンスを改善するための代替ファイルストアの設定に関するアイデアです。

まず最初にあなたのサーバで利用可能な速いファイルシステムを設置してください。
恐らく、あなたはMoodleをSSDにインストールしていると思いますが、ディスクスペースが高額になるため、moodledataディレクトリはSSDに設置されていないことでしょう。
あなたのSSDにディレクトリまたは小さなパーティションを作成して、そこでMoodleデータディレクトリの代わりに使用するファイルストアを作成することを考慮してください。

次にあなたに利用できる速いドライブがない場合、かつ多くの空き容量がある場合を考えます。
ドライブに小さなパーティションを作成して、パフォーマンス重視のファイルシステム設定を試してみても良いでしょう。
例えば昨今の多くのLinuxインストレーションではEXT4を使用しています。EXT4は素晴らしいファイルシステムですがジャーナリングのような機能が影響してオーバーヘッドが生じてしまいます。
パーティションを作成してパフォーマンスのために最適化されたファイルシステムを使用することにより、あなたが探していたものに近付くことでしょう。キャッシュは揮発性であることを念頭に設計されている点、またキャッシュのためのファイルシステムの選択はあなたのサーバのファイルシステムの選択とは異なる点に留意してください。

最後にあなたに十分な時間とサーバに十分なメモリがある場合、ramdisk/tmpfsを作成して、そこにファイルストアを指定することを考慮してください。 純粋にメモリをベースとした場合、キャッシュのように厳密に揮発性となり、ファイルシステムパフォーマンスはこれより良くなることはありません。
もちろん、あなたはスペースを制限してそのリソースをサーバから取り除くことができます。

これらのアイデアは単にアイデアであることに留意してください。
あなたがどのような選択をしたとしても - テスト、テスト、テストをして、あなたの決定が正しいことを確認してください。

Memcache

ファイル:caching-27-08-add-memcache-store.png
Memcacheストアの追加スクリーンショット

Memcacheストアインスタンスを追加できるようにしたい場合、最初にあなたがアクセスできるMemecachesサーバを準備して、ウェブサーバでMemcache php拡張モジュールをインストールおよび有効化する必要があります。

あなたはファイルストアのようにストア名を指定する必要があります。これは設定インスタンス内でストアインスタンスを識別するため使用されます。また、サイトでユニークである必要があります。
Memcacheストアの場合、あなたはMemcacheサーバを指定するか、Memcacheを使用するサーバを指定する必要があります。 サーバは1行あたり1台を記述してください。それぞれの行にはコロンで分けられた1つから3つのプロパティを含んでください。

  1. サーバのURLまたはIPアドレス (必須)
  2. サーバがリスニングしているポート (任意)
  3. このサーバに与える負荷 (任意)

例えば、あなたのサーバで2つのMemcachedインスタンスが動作している場合を考えます。1つの設定をデフォルトポート、もう1つの設定を11212にしたい場合、次のようになります。 127.0.0.1 127.0.0.1:11212

加えて、あなたは使用するキー接頭辞を指定することもできます。あなたがここで入力した内容はサーバにアクセスする前にすべてのキーの接頭辞として付加されます。そして、接頭辞を認識可能な方法でMemcacheスペースを効果的に分割するため使用できます。あなたがMemcacheサーバに何が保存されているか調査するためのツールを使用している場合、これは役に立ちます。

実装に関する重要なメモ

  • Memcache拡張モジュールは一連のエントリの削除する手段を提供しません。単一のエントリを削除するか、すべてのエントリを削除するかのみです。
    あなたがMoodle内のMemcacheストアを削除する場合、Memcacheバックエンド内のすべてのエントリが削除されてしまうことが理由であることに留意してください。これらはMoodleに関連しているだけではありません。
    これらの理由から専用のMemcachedサーバの使用を強くお勧めします。また、このサーバには他のソフトウェアが動作するよう設定しないでください。他のソフトウェアが動作するよう設定した場合、パフォーマンスが低下して逆の効果が出現することがあります。
  • 同様にあなたがMoodle内でセッションのキャッシングのためにMemecacheを使用する場合、2つのMemcachedサーバを使用する必要があります。1つはセッション用、そしてもう1つはキャッシング用です。そうでない場合、Moodleのキャッシュを削除することにより、あなたのセッションも削除されてしまいます!

Memcached

ファイル:caching-27-09-add-memcached-store.png
Memcachedストアを追加する スクリーンショット

最初にMemcacheストアと同様にあなたがアクセスできるMemcachedサーバを持つ必要があります。同時にあなたのサーバでMemcached PHP拡張モジュールをインストールおよび有効化する必要もあります。

また、MemecachedストアにはMemecacheストアのように設定に2つの必須パラメータがあります。

ストア名
設定インターフェース内のストアインスタンスを識別するために使用されます。また、サイトでユニークである必要があります。
サーバ
あなたがこのキャッシュを使用したいサーバです。詳細は以下のとおりです。

サーバは1行あたり1台を追加してください。それぞれの行にはコロンで分けられた1~3つのプロパティを記述できます。

  1. サーバのURLまたはIPアドレス (必須)
  2. サーバがリスニングしているポート (任意)
  3. このサーバに与える重み (任意)

例えば、あなたのサーバに2つのMemcachedインスタンスが動作しているとします。1つはデフォルトポート、もう1つはポート11212が設定されている場合、次のような設定になります: 127.0.0.1 127.0.0.1:11212

Memcachedストアを作成する場合、あなたが設定できるいくつかの任意のパラメータがあります。

圧縮を使用する
デフォルトは有効です。必要に応じて無効にしてください。
シリアライザを使用する
Memecacheサーバと通信する場合、あなたが使用するシリアライザを選択できるようにします。デフォルトではMemcached拡張モジュールおよびPHPで1つのシリアライザのみ提供できます。しかし、インストレーションに利用できる他のいくつかの方法もあります。1つの例として、igbinary (https://github.com/igbinary/igbinary) があります。
接頭辞キー
サーバとの通信の前にすべてのキーに付加する接頭辞をあなたが設定できるようにします。
ハッシュメソッド
Memcached拡張モジュールにより提供されるハッシュメソッドはここでデフォルトとして使用されます。あなたが希望すれば代替手段の使用を選択できます。利用可能なオプションに関して次をご覧ください: http://www.php.net/manual/en/memcached.constants.php ご希望でしたら、あなたのphp.ini内のデフォルトPHPハッシュ関数をオーバーライドすることもできます。
Buffer writes
Disabled by default, and for good reason. Turning on buffered writes will minimise interaction with the Memcached server by buffering io operations. The downside to this is that on a system with any concurrency there is a good chance multiple requests will end up generating the data because no one had pushed it to the Memcached server when they first requested it. Enabling this can be advantageous for caches that are only accessed in capability controlled areas for example where multiple interaction is taking a toll on network resources or such. But that is definitely on the extreme tweaking end of the scale.
バッファ書き込み Buffer writes
正当な理由でデフォルトでは無効にされています。バッファ書き込みを有効にすることにより、I/O処理をバッファしてMemcachedサーバとの通信を最小限にします。これに関する不都合な点は並列処理のシステムの場合、誰も最初のリクエスト時にデータをMemdadhesサーバにプッシュしないため、結局のところ複数のリクエストによりデータが生成されてしまうことです。この設定を有効にする利点はケイパビリティによってアクセスをコントロールされたエリアをキャッシュできることです。例えばネットワークリソース等に負荷の掛かる多重インタラクションが発生する場合です。しかし、これは結局のところ、スケールの最後の極端な調整と言えます。

Important implementation notes 重要な実装メモ

  • The Memcached extension does not provide a means of deleting a set or entries. Either a single entry is deleted, or all entries are deleted.

Because of this it is important to note that when you purge a Memcached store within Moodle it deletes ALL entries in the Memcached server. Not just those relating to Moodle.
For that reason it is highly recommended to use dedicated Memcached servers and to NOT configure any other software to use the same servers. Doing so may lead to performance depreciation and adverse affects.

  • Likewise if you want to use Memcached for caching and for sessions in Moodle it is essential to use two Memcached servers. One for sessions, and one for caching. Otherwise a cache purge in Moodle will purge your sessions!

MongoDB

MongoDB is an open source document orientated NoSQL database. Check out their website www.mongodb.org for more information.

Store name
Used to identify the store instance in the configuration interface and must be unique to the site.
Server
This is the connection string for the server you want to use. Multiple servers can be specified using a comma-separated list.
Database
The name of the database to make use of.
Username
The username to use when making a connection.
Password
The password of the user being used for the connection.
Replica set
The name of the replica set to connect to. If this is given the master will be determined by using the ismaster database command on the seeds, so the driver may end up connecting to a server that was not even listed.
Use
If enabled the usesafe option will be used during insert, get, and remove operations. If you've specified a replica set this will be forced on anyway.
Use safe value
You can choose to provide a specific value for use safe. This will determine the number of servers that operations must be completed on before they are deemed to have been completed.
Use extended keys
If enabled full key sets will be used when working with the plugin. This isn't used internally yet but would allow you to easily search and investigate the MongoDB plugin manually if you so choose. Turning this on will add an small overhead so should only be done if you require it.

ストアインスタンスにキャッシュをマッピングする Mapping a cache to a store instance

ファイル:caching-27-11-store-mapping.png
Cache definition store mapping screenshot

Mapping a store instance to a cache tells Moodle to use that store instance when the cache is interacted with. This allows the Moodle administrator to control where information gets stored and to most importantly optimise performance of your site by making the most of the resources available to your site.

To set a mapping first browse to the cache configuration screen.
Proceed to find the Known cache definitions table and within it find the cache you'd like to map. In the actions column select the link for Edit mappings.

The screen you are presented allows you to map one or more cache store instances to be used by this cache.
You are presented with several drop-downs that allow you to map one or more cached. All mapped caches get interacted with. The "Primary" store is the store that will be used first when interacting with the cache. The "Final" mapped store will be the last cache store interacted with.
How this interaction occurs is documented below.

If no stores are mapped for the cache then the default stores are used. Have a look at the section below for information on changing the default stores.

If a single store instance is mapped to the cache the following occurs:

Getting data from the cache
Moodle asks the cache to get the data. The cache attempts to get it from the store. If the store has it it gives it to the cache, and the cache gives it to Moodle so that it can use the data. If the store doesn't have it the a fail is returned and Moodle will have to generate the data and will most likely then send it to the cache.
Storing data in the cache
Moodle will ask the cache to store some data, and the cache will give it to the cache store.

If multiple store instances are mapped to the cache the following occurs:

Getting data from a store
Moodle asks the cache to get the data. The cache attempts to get it from the first store. If the first store has it then it returns the data to the cache and the cache returns it to Moodle. If the first store doesn't have the data then it attempts to get the data from the second store. If the second store has it it returns it to the first store that then stores it itself before returning it to the cache. If it doesn't then the next store is used. This continue until either the data is found or there are no more stores to check.
Storing data in the cache
Moodle will ask the cache to store some data, the cache will give it to every mapped cache store for storage.

The main advantage to assigning multiple stores is that you can introduce cache redundancy. Of course this introduces an overhead so it should only be used when actually required. The following is an example of when mapping multiple stores can provide an advantage:

Scenario:
You have have a web server that has a Moodle site as well as other sites.
You also have a Memcache server that is used by several sites including Moodle.

Memcache has a limited size cache, that when full and requested to store more information frees space by dropping the least used cache entries.

You want to use Memcache for your Moodle site because it is fast, however you are aware that it may introduce more cache misses because it is a heavily used Memcache server.

Solution:
To get around this you map two stores to caches you wish to use Memcache.
You make Memcache the primary store, and you make the default file store the final cache store.

Explanation:
By doing this you've created redundancy, when something is requested Moodle first tries to get it from Memcache (the fastest store) and if its not there it proceeds to check the file cache.

Just a couple more points of interest:

  • Mapping multiple caches will introduce overhead, the more caches mapped the more overhead.
  • Consider the cache stores you are mapping to, if data remains there once set then there is no point mapping any further stores after it. This technique is primarily valuable in situations where data is not guaranteed to remain after being set.
  • Always test your configuration. Enable the display of performance information and then watch which stores get used when interacting with Moodle in such a way as to trigger the cache.

マッピングが存在しない場合に使用されるストアに関する設定 Setting the stores that get used when no mapping is present

ファイル:caching-27-12-default-store-mapping.png
Setting which stores get used when no mapping is present screenshot

This is really setting the default stores that get used for a cache type when there is not a specific mapping that has been made for it.

To set a mapping first browse to the cache configuration screen.
Proceed to find the Stores used when no mapping is present table.
After the table you will find a link Edit mappings, click this.

On the screen you are presented with you can select one store for each cache type to use when a cache of the corresponding type gets initialised and there is not an explicit mapping for it.

Note that on this interface the drop downs only contain store instances that are suitable for mapping to the type. Not all instances will necessarily be shown. If you have a store instance you don't see then it is not suitable for ALL the cache definitions that exist.
You will not be able to make that store instance the default, you will instead need to map it explicitly to each cache you want/can use it for.

あなたのサイトのキャッシングを設定する Configuring caching for your site

This is where it really gets tricky, and unfortunately there is no step-by-step guide to this.

How caching can be best configured for a site comes down entirely to the site in question and the resources available to it.

What can be offered are some tips and tricks to get you thinking about things and to perhaps introduce ideas that will help you along the way.

If you are reading this document and you've learnt a thing or two about configuring caching on your site share your learnings by adding to the points here.

  • Plan it. It's a complex thing. Understand your site, understand your system, and really think how users will be using it all.
  • If you've got a small site the gains aren't likely to be significant, if you've got a large site getting this right can lead to a substantial boost in performance.
  • When looking at cache backends really research the advantages and disadvantages of each. Keep your site in mind when thinking about them. Depending upon your site you may find that no one cache backend is going to meet the entire needs of your site and that you will benefit from having a couple of backends at your disposal.
  • Things aren't usually as simple as installing a cache backend and then using it. Pay attention to configuration and try to optimise it for your system. Test it separately and have an understanding of its performance before tell Moodle about it. The cache allows you to shift load off the database and reduce page request processing.
    If for instance you have Memcache installed but your connection has not been optimised for it you may well find yourself in a losing situation before you even tell Moodle about the Memcache server.
  • When considering your default store instances keep in mind that they must operate with data sets of varying sizes and frequency. For a large site really your best bet is to look at each cache definition and map it to a store that is best suited for the data it includes and the frequency of access.
    Cache definitions have been documented Cache definitions.
  • Again when mapping store instances to caches really think about the cache you are mapping and make a decision based upon what you understand of your site and what you know about the cache.
    Cache definitions have been documented Cache definitions.
  • Test your configuration. If you can stress test it even better! If you turn on performance information Moodle will also print cache access information at the bottom of the screen. You can use this to visually check the cache is being used as you expect, and it will give you an indication of where misses etc are occurring.
  • Keep an eye on your backend. Moodle doesn't provide a means of monitoring a cache backend and that is certainly something you should keep an eye on. Memcache for instance drops least used data when full to make room for new entries. APC on the other hand stops accepting data when full. Both will impact your performance if full and you're going to encounter misses. However APC when full is horrible, but it is much faster.

パフォーマンステストに関する詳細情報 More on performance testing

Two links that might be useful to anyone considering testing performance on their own servers:

負荷分散さらたウェブサーバのパフォーマンスに関するアドバイス Performance advice for load-balanced web servers

  1. In Moodle 2.4 onwards with load-balanced web servers, don't use the default caching option that stores the data in moodledata on a shared network drive. Use memcached instead. See Tim Hunt's article on http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html
  2. In Moodle 2.6 onwards make sure you set $CFG->localcachedir to some local directory in config.php (for each node). This will speed up some of the disk caching that happens outside of MUC, such as themes, javascript, libraries etc.

トラブルシューティング Troubleshooting

Have you encountered a problem, or found yourself in a conundrum? Perhaps the answer is in this section. If its not when you find have an answer how about sharing it here.

詳細情報 More information


Cache related forum discussions that may help in understanding MUC:


Other:

関連情報