「キャッシング」の版間の差分
Mitsuhiro Yoshida (トーク | 投稿記録) |
Mitsuhiro Yoshida (トーク | 投稿記録) |
||
| 316行目: | 316行目: | ||
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! | 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! | ||
そのため、あなたがMoodleのキャッシングおよびセッションにMemcachedを使用したい場合、2台のMemcachedは必ず必要です。1つはセッション用、もう一つはキャッシング用です。そうでなければ、Moodleのキャッシュ削除があなたのセッションを削除してしまうことになります! | |||
===MongoDB=== | ===MongoDB=== | ||
2020年3月4日 (水) 15:02時点における版
作成中です - Mitsuhiro Yoshida (トーク)
キャッシュは負荷の高いデータベースクエリを避け再利用する目的で手元に置くための一群の処理済みデータです。
Moodle 2.4以降、MUC (Moodle Universal Cache) が実装されました。この新しいシステムによりMoodleの特定の機能 (例 ストリング取得) で異なるインストール済みキャッシュサービスを利用できます (例 files、ram、memcached)。
私たちは将来的なMoodleのバージョンでも継続してMUCを使用する機能を拡張します。これによりパフォーマンスが改善されますが、今からでも、あなたのサイトのパフォーマンスを改善できます。
パフォーマンステストに関する一般的なアプローチ
以下、あなたが取るべき一般的な戦略です:
- 可能な限り、あなたの実運用インスタンスに近いテスト環境を構築してください (例 ハードウェア、ソフトウェア、ネットワーク等)
- 可能な限り、この環境から多くの管理外の変数を削除するようにしてください (例 他のサービス)。
- あなたのサーバでシミュレーションおよび繰り返し処理の実行および実際の動作を再現できるツールを使用してください (例 jmeterまたはselenium)。
- データ (Ram、ロード、所要時間等) を取得してサーバのパフォーマンスを計測する方法を決定してください。
- あなたのテスト環境を実行してベースラインパフォーマンス結果を計測してください。
- 同時に変数を変更してパフォーマンスが良くなるか悪くなるか確認するため、テスト環境を再度実行してください。必要に応じて処理を繰り返してください。
- 継続的なパフォーマンスの改善をもたらす設定を探り当てた場合、あなたの実運用サイトに適用してください。
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ディレクトリにデータを保存します。
- セッションストアインスタンスはすべてのセッションキャッシュに使用するため作成されます。
- スタティックメモリストアインスタンスはすべてのリクエストキャッシュタイプに使用するため作成されます。メモリ内のデータはリクエストの存続期間のみ存在します。
キャッシュ: コード内では何が起きているのか
キャッシュはコード内で作成され、開発者が確認する必要のあるデータを保存するため使用されます。
恐らく、あなたは開発者ではないでしょうから、このセクションで分かりやすく簡単に説明してみましょう。あなたが知るべき極めて重要なことが１点あります。
開発者はデータがどこにキャッシュされるかに関して知ることはありません。使用するキャッシュを作成する場合、開発者は以下の情報を指定する必要があります。
- 必要なキャッシュタイプ
- このキャッシュが属するコードのエリア (あなたがAPIを使用する場合はAPI)
- キャッシュ名 (キャッシュが何に使われるのか表した言葉)
いくつかの指定できる任意の必須条件および設定もありますが、現時点では心配しないでください。
重要な点は開発者が使用するキャッシュバックエンドを選択できないこと、また、前述の3つのタイプから必要なキャッシュタイプを選択できるのみであることです。
どのようにして繋ぎ合せるのか
以下、組織内でのロールに関して説明します。
- システム管理者はあなたが使用できるMemcache、XCache、APCのようなキャッシュバックエンドをインストールします。
Moodleはこれらに関して知りません。これらはMoodleの範囲外であり、純粋にあなたのシステム管理者に責任があります。 - それぞれのバックエンドをサイトで利用できるようMoodle管理者がキャッシュストアインスタンスを作成します。
それぞれのバックエンドには1つまたはそれ以上のキャッシュストアを置くことができます。Memcachedのようなバックエンドには1つのバックエンド内に複数の別々のスペースを作成できる設定があります。 - 開発者はコード内でキャッシュを作成して、それをデータ保存のために使用します。
開発者はあなたがキャッシュをどのように使用するか知りません。開発者はキャッシュを作成して、最適なキャッシュタイプをMoodleに伝えるのみです。 - Moodle管理者はキャッシュストアとキャッシュ間のマッピングを作成します。
そのマッピングは開発者がキャッシュしたいデータを保存するため、あなたが指定したバックエンドを使用するようMoodleに伝えます。
加えて、あなたはさらに以下のことができます。
- あなたは多くのキャッシュを単一のキャッシュストアインスタンスにマッピングできます。
- あなたは複数のキャッシュストアインスタンスを単一のキャッシュに優先度 (最初... 最後) を付けてマッピングできます。
- あなたは特定のマッピングを持たないタイプのキャッシュすべてに使用されるデフォルトストアとしてキャッシュストアインスタンスをマッピングできます。
これがあなたにとってMoodleユニバーサルキャッシュに関する資料を読むのが最初である場合、非常に複雑に思えるかもしれませんが、心配しないでください。私たちはMoodle内でのキャッシング設定に取り組むため、Moodleユニバーサルキャッシュの詳細に関して取り上げます。
高度な概念
以下の概念は多くのサイトでは知る必要のない、または関わる必要のないものです。
あなたが共有バックエンドを持つクラスタサーバで規模の大きなサイトを運用している場合、またはサイト間で情報が共有されている複数サイトアーキテクチャでサイトを運用中でありパフォーマンスを最大にする方法を探している場合のみ、ここからお読みください。
ロッキング
ロッキングのアイデアに新しいものは何もありません。ロッキングは並列問題を避けるためアクセスをコントロールする処理です。
MUCは2つ目のタイプのプラグインであり、ロックが必要な場合に使用されるキャッシュロックプラグインです。今までキャッシュを必要としませんでした。元来、キャッシュは不安定なものであり、極めて重要なデータはデータベースのような永続的なデータストアに保存すべきです。
それにもかかわらず、オプション内でキャッシュ定義を要求してキャッシュストアインスタンスとの通信時に適用されるロッキングシステムがあります。
共有
キャッシュ内で保存されるデータすべてのビットには関連付けるために計算されたユニークキーがあります。
デフォルトではキーの一部はサイト特有のキャッシュにコンテンツを保存する際のサイトIDです。ほとんどのサイトで正にあなたが必要としているものです。
しかし、いくつかの場面では複数サイトを許可したり、キャッシュデータを共有するために何らかの形でサイトをリンクすることは有益です。
もちろん、すべてのキャッシュを共有できるということではありません。しかし、共有で負荷を減らして利用できるリソースを増やすことにより、確実にパフォーマンスを改善できる場合があります。
これは高度な機能であり、あなたが共有を選択する場合、注意して設定してください。
共有を使用する場合、あなたは情報を共有したいサイトのキャッシュストアインスタンスを最初に同じ設定する必要があります。それぞれのサイトでキャッシュの共有を同一の設定値に設定してください。
- 同じサイトIDのサイト
- これはデフォルトです。キャッシュ情報を共有するため同じサイトIDのサイトが許可されます。これは最も制限のあるものですがすべてのキャッシュで動作します。他のオプションにはリスク要因があるため、アクセス可能なサイトすべてにおいてキャッシュ情報を利用できることを確実にしてください。
- 同じバージョンで動作しているサイト
- バックエンドにアクセスする同じバージョンのMoodleサイトすべてはキャッシュストアに保存されたキャッシュ情報を共有できます。
- カスタムキー
- あなたはここで共有に使用するキーを手動入力できます。あなたが情報を共有したい他のサイトと同じキーを入力してください。
- 誰でも
- キャッシュ済みデータにはデータにアクセスできる他のサイトすべてからアクセスできます。このオプションでは一連のMoodle管理者にすべての権限を与えます。
例えばAPCがインストールされているサーバで同じバージョンの複数のMoodleが動作している場合、あなたは言語キャッシュをAPCストアにマップして同じバージョンが動作しているサイトすべてに共有を設定できます。
同じバージョンのサイトの言語キャッシュの共有は多くの場合において安全です。APCは極めて速く、言語キャッシュは実際にはすべてのページで使用されます。これら3点はあなたのサイトのパフォーマンスを大幅に上げることでしょう。
言語キャッシュを考慮することは大切です。すべての言語のキャッシュをサイト間で共有した場合、独自に修正した部分も共有されます。
キャッシュ設定画面
あなたはキャッシュ設定でMoodleのキャッシングに関するすべてを設定できます。
ここでは現在、あなたのサイトがどのように設定されている概要を示します。また、必要に応じて設定操作方法のリンクすべてを提供します。
キャッシュ設定画面にアクセスする
キャッシュ設定画面には「moodle/site:config」ケイパビリティのあるユーザのみアクセスできます。デフォルトではサイト管理者のみアクセスできます。
設定画面はログイン後の「管理 > プラグイン > キャッシング > 設定」にあります。
キャッシュストアをインストールする
ここではあなたがインストールしたキャッシュストアプラグインを一覧表示します。
あなたはそれぞれのプラグインを使用できるかどうか (すべてのPHP要件に合致しているか)、このサイトですでにいくつのストアインスタンスが存在するか、このストアが使用できるキャッシュタイプ、サポートされる (高度な) 機能およびこのストアに関して実行できる操作を素早く確認できます。
ほとんどの場合、可能な操作は新しいストアインスタンスを作成するのみです。
ほとんどのストアは複数インスタンスをサポートしますが、すべてではありません。例えばセッションキャッシュおよび静的リクエストキャッシュは複数インスタンスをサポートしません。これら2つのストアに関しては複数インスタンスを持つことに意味はありません。
設定済みストアインスタンス
以下、このサイトであなたが取得できるキャッシュストアの一覧です。
- ストア名
- このキャッシュストアの作成時にあなたが識別するためにつけた名称です。あなたが好きな名称を使えます。また、あなたがストアインスタンスを識別するためだけに使用されます。
- プラグイン
- このインスタンスのキャッシュストアプラグインです。
- 準備完了
- 接続またはセットアップ要件が確認されると共にPHP要件が合致した時点でチェックマークが表示されます。
- ストアマッピング
- このストアインスタンスに明確にマッピングされたキャッシュ数です。デフォルトマッピングの使用は含みません (以下で取り上げます)。
- モード
- このキャッシュインスタンスが提供できるモードです。
- サポート
- このキャッシュストアインスタンスでサポートされている機能です。
- ロッキング
- ロッキングはデータが上書きされないようキャッシュデータへのアクセスを1度に1プロセスのみに制限するためのメカニズムです。ロッキングメソッドはロックの取得および確認方法を決定します。
- 操作
- このキャッシュストアに対して実行できるすべての操作です。
既知のキャッシュ定義
ここではキャッシュ定義のアイデアはまだ考察されていません。これは管理者によって管理されるものです。開発者がキャッシュを作成する場合、2つの方法があります。最初の方法ではキャッシュ定義を作成します。これは基本的にどのようなキャッシュを作成したのかをMoodleに伝えます。2番目の方法はアドホック (Adhoc 限定目的) のキャッシュを作成することです。開発者は常に最初の方法を取ることをお勧めします。定義のあるキャッシュのみマップできます。また、管理者は定義のあるキャッシュのみさらに設定できます。アドホックキャッシュはデフォルト設定のみ使用します。
通常、アドホックキャッシュはキャッシュが小さい場合のみ許可されます。アドホックキャッシュのサイズがデフォルトより大きくなった場合、管理者に利点はありません。これは管理者にあなたのキャッシュに関わらないでくださいと言っているようなものです。
あなたはここで表示されているキャッシュから以下の情報を取得できます:
- 定義
- キャッシュに関する簡単な説明です。
- モード
- このキャッシュのキャッシュタイプです。
- コンポーネント
- キャッシュが割り当てられるコードコンポーネントです。
- エリア
- このキャッシュがコンポーネント内で提供されるコードのエリアです。
- ストアマッピング
- このキャッシュに使用されるストアです。
- 共有
- このサイトの共有設定です。
- 操作
- このキャッシュで実行されるすべての操作です。一般的にあなたはキャッシュストアを編集、共有を編集、キャッシュを削除できます。
あなたにはこのテーブルの最下部に「定義を再スキャンする」リンクが表示されます。このリンクをクリックすることにより、Moodleがすべてのコンポーネントおよびインストール済みプラグインをチェックしてキャッシュ定義の変更点を探します。しかし、あなたがそこにないキャッシュを探すのでしたら、試してみる価値はあります。
また、開発者がキャッシュで作業する場合、変更点をすぐに提供できる点も便利です。キャッシュ定義を調整する時にどの設定が最良であるのか探す場合も便利です。
特定のキャッシュ定義に関する情報はキャッシュ定義ページをご覧ください。
キャッシュロックインスタンス概要
上で言及したようにキャッシュのロッキングはMUCの高度な概念です。
ここでテーブルはMUCで利用可能なロッキングメカニズムの設定情報を表示します。デフォルトでは次の単一のロッキングメカニズムのみ利用できます: ファイルロッキング
現在、これを使用しているキャッシュは存在しないため、これ以上ここで説明しません。
マッピングが存在しない場合に使用するストア
このテーブルでは適当なマッピングが存在しない場合にどのキャッシュストアインスタンスが使用されるか簡単に示しています。
これをシンプルにするため、ここではそれぞれのタイプのデフォルトのキャッシュストアを表示します。
最後に「マッピングを編集する」ボタンがあります。あなたはこのボタンによりマッピングを設定するページに移動できます。
キャッシュストアインスタンスを追加する
デフォルト設定はすべてのサイトで動作します。しかし、あなたのサイトのパフォーマンスを多様なキャッシュバックエンドおよび技術により改善できます。あなたが取り組みたい最初のことはセットアップしたキャッシュバックエンドに接続するため設定されたキャッシュストアインスタンスを追加することでしょう。
ファイルキャッシュ
あなたには「インストール済みキャッシュストア」テーブルにファイルキャッシュプラグインが表示されます。「インスタンスを追加する」をクリックしてファイルキャッシュストアインスタンスの追加処理を開始してください。
ファイルキャッシュを作成する場合、実際のところ、必須パラメータはストア名1つのみです。ストア名は設定インターフェースでファイルストアインスタンスを認識するために使用されます。ストア名はサイト内でユニークである必要があります。 あなたが好きなストア名にできますが、ファイルストアの使用目的を意図した名称にすることをお勧めします。
ファイルキャッシュの場所および使用目的に関して次のプロパティも指定およびカスタマイズできます。
- キャッシュパス
- あなたはファイルシステムへのキャッシュデータ保存時に使用するディレクトリを指定できます。もちろん、ウェブサーバのユーザにはこのディレクトリへの読み書き権が必要です。デフォルト (空白) ではMoodleデータディレクトリが使用されます。
- 自動ディレクトリ作成
- この設定を有効にした場合、キャッシュ作成時に指定されたディレクトリが存在しない場合にMoodleは自動的にディレクトリを作成します。ディレクトリが指定されたにも関わらず存在しない場合、キャッシュは準備できていないと見なされ使用されません。
- 単一ディレクトリストア
- デフォルトでファイルストアはデータを保存するためのサブディレクトリ構造を作成します。データキーの最初の3文字はディレクトリ名に使用されます。これはディレクトリあたりの最大ファイル数を持つファイルシステムの制限を回避するため有用です。このオプションを有効にした場合、ファイルキャッシュはデータの保存にサブディレクトリを使用しません。これによりフラットな構造になりますが、ファイルシステムの制限に達する可能性があります。使用には注意してください。
- ディレクトリを事前スキャンする
- ファイルキャッシュが提供する機能の1つにキャッシュ初回使用時のストレージディレクトリの事前スキャンがあります。これにより詳細な読み込みを犠牲にすることでファイルを素早くチェックできます。
ファイルキャッシュストアはアプリケーションキャッシュに使用されるデフォルトのストアです。デフォルトではmoodledataディレクトリがキャッシュに使用されます。 サーバの負荷が増えた場合、ファイルアクセスに負担がかかる場合があります。以下、パフォーマンスを改善するための代替ファイルストア設定に関するアイデアです。
まず、最初にあなたのサーバに利用可能な速いファイルシステムを設置してください。
恐らく、あなたはMoodleをSSDにインストールしていると思いますが、ディスクスペースが高額になるため、moodledataディレクトリはSSDに設置されていないことでしょう。
あなたのSSDにディレクトリまたは小さなパーティションを作成して、そこでMoodleデータディレクトリの代わりに使用するファイルストアの作成を考慮してください。
次にあなたに利用できる速いドライブがない場合、かつ多くの空き容量がある場合を考えます。
ドライブに小さなパーティションを作成してパフォーマンス重視のファイルシステム設定を試してみても良いでしょう。
例えば昨今の多くのLinuxインストレーションではEXT4を使用しています。EXT4は素晴らしいファイルシステムですが、ジャーナリングのような機能が影響してオーバーヘッドが生じてしまいます。
パーティションを作成してパフォーマンスのために最適化されたファイルシステムを使用することにより、あなたが探していたものに近付くことでしょう。キャッシュが揮発性であることを念頭に設計されている点、またキャッシュのためのファイルシステムの選択はあなたのサーバのファイルシステムの選択とは異なる点に留意してください。
最後にあなたに十分な時間\、そしてサーバに十分なメモリがある場合、ramdisk/tmpfsを作成して、そこにファイルストアを指定することを考えてください。
純粋にメモリをベースとした場合、キャッシュのように厳密に揮発性となるため、ファイルシステムパフォーマンスはこれより良くなることはありません。
もちろん、あなたはスペースを制限してそのリソースをサーバから取り除くことができます。
これらのアイデアは単にアイデアに過ぎないことに留意してください。
どのような選択をしたとしても - テスト、テスト、テストをして、あなたの決定が正しいことを確認してください。
Memcache
Memcacheストアインスタンスを追加できるようにしたい場合、最初にあなたがアクセスできるMemecachesサーバを準備して、ウェブサーバでMemcache php拡張モジュールをインストールおよび有効化する必要があります。
あなたはファイルストアのようにストア名を指定する必要があります。これは設定インスタンス内でストアインスタンスを識別するため使用されます。また、サイトでユニークである必要があります。
Memcacheストアの場合、あなたはMemcacheサーバを指定するか、Memcacheを使用するサーバを指定する必要があります。
サーバは1行あたり1台を記述してください。それぞれの行にはコロンで分けられた１つから3つのプロパティを含んでください。
- サーバのURLまたはIPアドレス (必須)
- サーバがリスニングしているポート (任意)
- このサーバに与える負荷 (任意)
例えば、あなたのサーバで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
最初にMemcacheストアと同様にあなたがアクセス可能なMemcachedサーバを持つ必要があります。同時にあなたのサーバでMemcached PHP拡張モジュールをインストールおよび有効化する必要もあります。
また、MemecachedストアにはMemecacheストアのように2つの必須パラメータが設定にあります。
- ストア名
- 設定インターフェース内のストアインスタンスを識別するために使用されます。また、サイトでユニークである必要があります。
- サーバ
- あなたがこのキャッシュを使用したいサーバです。詳細は以下のとおりです。
サーバは1行あたり1台を追加してください。それぞれの行にはコロンで分けた1～3個のプロパティを記述できます。
- サーバのURLまたはIPアドレス (必須)
- サーバがリスニングしているポート (任意)
- このサーバに与える重み (任意)
例えば、あなたのサーバに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
- 正当な理由でデフォルトでは無効にされています。バッファ書き込みを有効にすることにより、I/O処理をバッファしてMemcachedサーバとの通信を最小限にします。これに関する不都合な点は並列処理のシステムの場合、誰も最初のリクエスト時にデータをMemdadhesサーバにプッシュしないため、結局のところ、複数のリクエストによりデータが生成されてしまうことです。この設定を有効にする利点はケイパビリティによってアクセスをコントロールされたエリアをキャッシュできることです。例えばネットワークリソース等に負荷の掛かる多重インタラクションが発生する場合です。しかし、これは結局のところ、スケールの最後の極端な調整と言えます。
実装に関する重要なメモ
- Memcached拡張モジュールでは一連のエントリの削除手段を提供しません。単一エントリまたはエントリすべてが削除されてしまいます。
あなたがMoodle内のMemecacheストアを削除する場合、Memcachedサーバ内のエントリすべてが削除されてしまうことに留意してください。これはMoodleだけに関係することではありません。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
この理由のため、Memcached専用サーバの使用を強くお勧めします。同じサーバで同時に他のソフトウェアを動作させないでください。多くのソフトウェアを動作させることにより、結果としてパフォーマンスの低下および好ましくない影響が生じる可能性があります。1つはセッションのため、もう1つはキャッシングのためです。そうでない場合、Moodleのキャッシュ削除があなたのセッションを削除します!
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! そのため、あなたがMoodleのキャッシングおよびセッションにMemcachedを使用したい場合、2台のMemcachedは必ず必要です。1つはセッション用、もう一つはキャッシング用です。そうでなければ、Moodleのキャッシュ削除があなたのセッションを削除してしまうことになります!
MongoDB
MongoDBはオープンソースのドキュメント指向データベースです。 詳細はMongoDBの公式サイトをご覧ください: www.mongodb.org
- ストア名
- 設定インターフェース内でのストアインスタンスの識別のために使用されます。また、サイトでユニークである必要があります。
- サーバ
- これはあなたが使用したいサーバのための接続ストリングです。複数のサーバはカンマ区切りの一覧で指定できます。
- データベース
- 使用するデータベースのデータベース名です。
- ユーザ名
- 接続時に使用するユーザ名です。
- パスワード
- 接続時に使用するユーザのパスワードです。
- レプリカセット
- 接続先のレプリカセット名です。これが提供された場合、シード時に「ismaster」データベースコマンドを使用してマスターが決定されます。結果として、ドライバはリストにないサーバであっても接続できます。
- 使用
- この設定を有効にした場合、追加、取得および削除処理中にusesafeオプションが使用されます。あなたがレプリカセットを指定した場合、これが強制されます。
- 安全値を使用する
- あなたは安全に使用するため特定の値を提供できます。これは完了したと見なされる前に処理を完了しなければならないサーバ数を決定します。
- 拡張キーを使用する
- この設定を有効にした場合、完全なキーセットがプラグイン連携時に使用されます。これは内部的には使用されませんが、あなたは必要に希望に応じて簡単にMongoDBプラグインを手動で検索および調査できます。この設定を有効にした場合、少しだけ負荷が掛かるため、必要な場合のみ有効にしてください。
ストアインスタンスにキャッシュをマッピングする
ストアインスタンスをキャッシュにマッピングすることにより、キャッシュとやりとりする時にそのストアインスタンスを使うようMoodleに伝えます。これによりMoodle管理者は情報が保存される場所をコントロールできます。また、何よりもまず、あなたのサイトで利用可能なリソースを最大限活用することにより、パフォーマンスを最適化できます。
マッピングを設定するには最初にキャッシュ設定画面を閲覧してください。
「既知のキャッシュ定義」テーブルを探して、その中からあなたがマップしたいキャッシュを探してください。
操作カラムで「マッピングを編集する」リンクを選択してください。
あなたは表示される画面でこのキャッシュで使用するため1つまたはそれ以上のキャッシュストアインスタンスをマップできます。
あなたは表示されたいくつかのドロップダウンメニューで1つまたはそれ以上のキャッシュをマップできます。マップされたキャッシュすべては相互に情報をやりとりします。「主」ストアはキャッシュとのやりとりの最初に使われるキャッシュです。
「最終」マップストアは情報をやりとりする最後のキャッシュです。
以下、この情報のやりとりがどのように発生するか説明します。
キャッシュのストアがマップされない場合、デフォルトストアが使用されます。デフォルトストアの変更に関して以下のセクションをお読みください。
単一のストアインスタンスがキャッシュにマップされた場合、以下のようになります:
- キャッシュからデータを取得する
- Moodleはキャッシュにデータを取得するよう依頼します。キャッシュはストアからデータの取得を試みます。ストアにデータが存在する場合、ストアはMoodleで使用できるようキャッシュにデータを渡します。ストアにデータが存在しない場合、「fail」が戻されてMoodleはデータを生成しなければなりません。そして、殆どの場合、生成したデータをキャッシュに送ります。
- キャッシュにデータを保存する
- Moodleはキャッシュにデータを保存するよう依頼します。そして、キャッシュはデータをキャッシュストアに渡します。
複数ストアインスタンスがキャッシュにマップされた場合、以下のようになります:
- ストアからデータを取得する
- Modleはキャッシュにデータを取得するよう依頼します。キャッシュは最初のストアからのデータ取得を試みます。最初のストアがデータを取得した場合、ストアはキャッシュにデータを戻してキャッシュはデータをMoodleに戻します。最初のストアにデータがない場合、2番目のストアからのデータ取得を試みます。2番目のストアにデータがある場合、最初のストアにデータを戻してデータをキャッシュに戻す前に保存します。そうでない場合、次のストアが使用されます。これはデータが見つからなくなるか、チェックするストアがなくなるまで続きます。
- キャッシュにデータを保存する
- Modleはキャッシュにデータを保存するよう依頼します。キャッシュは保存のためにすべてのマップ済みキャッシュストアにデータを渡します。
複数ストアを割り当てる主な利点はあなたがキャッシュ冗長性を導入できることにあります。もちろん、これによりオーバヘッドが発生してしまうため、本当に必要な場合のみ使用してください。 以下、複数ストアのマッピングが利点を提供できる例です:
シナリオ: あなたにはMoodleサイトおよび他のサイトが設置されたウェブサーバがあります。 また、あなたはMoodleを含む複数のサイトで使用されるMemcacheサーバがあります。 Memcacheはサイズ制限のあるキャッシュです。キャッシュがフルの時にさらに情報ツリーのスペースを要求された場合、最も使われていないキャッシュを削除してスペースが空けられます。 Memcacheが速いため、あなたのMoodleサイトに使いたいと思います。しかし、Memcacheサーバが過度に使用されているため、頻繁にキャッシュ喪失を経験することに気が付きます。 ソリューション: この問題を回避するため、あなたが使用したいMemcacheのキャッシュの2つのストアをマップします。 あなたはMemcacheを主ストアにします。また、デフォルトファイルストアを最終キャッシュストアにします。 説明: これを実現するため、あなたは冗長を作成しました。何かがMoodleにリクエストする場合、最初にMemcache (最速のストア) から取得を試みます。そこにない場合、ファイルキャッシュを確認します。
いくつかの興味深い点:
- 複数キャッシュをマップすることでオーバーヘッドが増大します。キャッシュのマップが増えるほどオーバーヘッドも増大します。
- あなたがマップするキャッシュストアを考えてみましょう。設定されたデータがキャッシュに保持されたままになった場合、それ以上、ストアをマップできなくなります。このテクニックは主に設定された後のデータの保持が保証されない場合に価値があります。
- 常にあなたの設定をテストしてください。パフォーマンス情報の表示を有効にして、どのストアがキャッシュを動作させるような方法でMoodleとの情報のやり取りに使用されるか確認してください。
マッピングが存在しない場合に使用されるストアに関する設定
これは特定のマッピングが存在しない場合にキャッシュタイプに使用されるデフォルトストアの実際の設定です。
マッピングを設定するには最初にキャッシュ設定画面を表示してください。
「マッピングが存在しない場合に使用されるストア」テーブルを探してください。
テーブルの下に「マッピングを編集する」リンクがあります。そのリンクをクリックしてください。
関連するタイプのキャッシュが初期化された場合、あなたにはそれぞれのキャッシュタイプに使用できる1つのストアを選択できる画面が表示されます。これには明示的なマッピングはありません。
このインターフェースにおいて、タイプへのマッピングに適切なストアインスタンスのみがドロップダウンメニューに含まれることに留意してください。
すべてのインスタンスを表示する必要はありません。あなたに表示しないストアインスタンスがある場合、存在する「すべて」のキャッシュ定義は適切ではありません。
あなたはこのストアインスタンスをデフォルトにはできません。代わりにこのストアインスタンスを使用したいキャッシュに明確にマップする必要があります。
あなたのサイトのキャッシングを設定する
これは本当に微妙な場所であり、残念ながら、これに関してステップバイステップのガイドはありません。
どのようしてキャッシュを最良の状態に設定するかは問題となるサイトおよび利用可能なリソースに完全に依存します。
あなたが何を提供できるかは今後物事を考えてアイデアを生み出すためのヒントとなります。
このドキュメントを読んでキャッシュの設定に関して1つまたは2つを学べた場合、ここに追加することであなたの学びを共有してください。
- キャッシングを計画してください。キャッシングは複雑なものです。あなたのサイトを理解してください。あなたのシステムを理解してください。そして、あなたのユーザがキャッシュをどのように使うのか十分に考えてください。
- あなたのサイトの規模が小さい場合、顕著な効果は望めない可能性があります。あなたのサイトの規模が大きい場合、キャッシングを正しく設定することでパフォーマンスを十分に向上できます。
- キャッシュバックエンドを判断する場合、メリットおよびデメリットを十分に考えてください。メリットおよびデメリットを考える場合、あなたのサイトのことを留意してください。あなたのサイトによりますが、1つのキャッシュバックエンドだけではサイト全体の要求を満たすことができず、自由に複数のバックエンドを持つことにより利益を享受できる場合もあります。
- 通常、キャッシュバックエンドのインストールおよび使用のように簡単ではありません。キャッシングに関して設定および最適化に注意を払ってください。キャッシングを別の場所でテストした後、Moodleに伝える前にパフォーマンスに関して理解してください。キャッシュにより、あなたはデータベースの負荷を軽減してページリクエスト処理を減らせます。
例えばMemcacheがインストールされているにも関わらず接続が最適化されていない場合、あなたはMoodleにMemcacheサーバに関して伝える前に損失に気付くことでしょう。 - あなたのデフォルトインスタンスを考慮する場合、様々なサイズおよび頻度のデータで動作する必要がある点を留意してください。大規模なサイトではそれぞれのキャッシュ定義を確認して含まれるデータおよびアクセス頻度に最適なストアにマップすることが最善の策です。
キャッシュ定義に関してキャッシュ定義でドキュメントが作成されています。 - 再度、キャッシュにストアインスタンスをマップする場合、あなたがマッピングするキャッシュに関して熟考してください。そして、あなたのサイトに関して把握している点、およびキャッシュに関して理解している点を基に決定してください。
キャッシュ定義に関してキャッシュ定義でドキュメントが作成されています。 - あなたの設定をテストしてください。あなたがストレステストをできるのであれば、さらに良くなります! あなたがパフォーマンス情報を有効にした場合、Moodleは画面下部にキャッシュアクセス情報を表示します。あなたの希望通りにキャッシュが動作しているか視覚的に確認できます。そして、失敗等が発生している場所を把握できます。
- あなたのバックエンドを監視してください。Moodleはキャッシュバックエンドを監視するための手段を提供しないため、あなたは確実に監視すべきです。インスタンスのMemcacheは新しいエントリのスペースを空けるため、最も使われていないデータを削除します。それに対してAPCはエントリのスペースが満杯の場合にデータの受け取りを停止します。エントリのスペースが満杯でエントリの喪失に遭遇する場合、両者ともにパフォーマンスに影響を及ぼします。しかし、スペースが満杯の場合、APCは酷いことになるのですが、他に比べて速さだけはあります。
パフォーマンステストに関する詳細情報
以下、2つのリンクはサーバのパフォーマンスを向上させるために有益な内容です:
負荷分散されたウェブサーバのパフォーマンスに関するアドバイス
- ロードバランサが設置されたウェブサーバの場合、Moodle 2.4以降ではデフォルトで共有ネットワークドライブのmodoeldata内データにキャッシュを保存するオプションを使用しません。代わりにmemcachedを使用します。詳細はTim Huntさんの記事をご覧ください: http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html
- Moodle 2.6以降、config.phpの「$CFG->localcachedir」でのローカルディレクトリ設定を確認してください (各ノードに関して)。これはテーマ、JavaScript、ライブラリ等のMUC外部のディスクキャッシュをスピードアップします。
トラブルシューティング
問題に遭遇しましたか、それともあなた自身では解決困難な状況になりましたか? 恐らく、答えはこのセクションにあります。そうでない場合、あなたが答えを見つけ次第、ここで共有してはいかがでしょうか。
詳細情報
- キャッシュ定義 Moodle内のキャッシュ定義に関する情報
- キャッシュAPI キャッシュAPI詳細
- キャッシュAPI - クイックリファレンス キャッシュAPIのページに焦点を置いた短いコード
- Moodleユニバーサルキャッシュ (Moodle Universal Cache MUC) オリジナルキャッシュ仕様
MUCの理解に役立つキャッシュ関連のフォーラムディスカッション
その他:
- Moodle 2.4.5 vs. 2.5.1 パフォーマンスおよびMUC APCキャッシュストア ブログ記事 by Justin Filip
