「キャッシング」の版間の差分
Mitsuhiro Yoshida (トーク | 投稿記録) |
Mitsuhiro Yoshida (トーク | 投稿記録) |
||
| 165行目: | 165行目: | ||
; '''サポート''' : このキャッシュストアインスタンスでサポートされている機能です。 | ; '''サポート''' : このキャッシュストアインスタンスでサポートされている機能です。 | ||
; '''Locking ''' : Locking is a mechanism that restricts access to cached data to one process at a time to prevent the data from being overwritten. The locking method determines how the lock is acquired and checked. | ; '''Locking ''' : Locking is a mechanism that restricts access to cached data to one process at a time to prevent the data from being overwritten. The locking method determines how the lock is acquired and checked. | ||
; '''ロッキング''' : | ; '''ロッキング''' : ロッキングはデータが上書きされないようキャッシュデータへのアクセスを1度に1プロセスのみに制限するためのメカニズムです。ロッキングメソッドはロックの取得および確認方法を決定します。The locking method determines how the lock is acquired and checked. | ||
; '''Actions''' : Any actions that can be performed against this cache store instance. | ; '''Actions''' : Any actions that can be performed against this cache store instance. | ||
2019年2月16日 (土) 15:11時点における版
作成中です - 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つのストアに関しては複数インスタンスを持つことに意味はありません。
設定済みストアインスタンス Configured store instances
以下、このサイトであなたが取得できるキャッシュストアの一覧です。
- ストア名
- このキャッシュストアの作成時にあなたが識別するためにつけた名称です。あなたが好きな名称を使うことができます。また、あなたがストアインスタンスを識別するためだけに使用されます。It
- プラグイン
- このインスタンスのキャッシュストアプラグインです。
- 準備完了
- 接続またはセットアップ要件が確認されると共にPHP要件が合致した場合にチェックマークが表示されます。
- ストアマッピング
- このストアインスタンスに明確にマッピングされたキャッシュ数です。デフォルトマッピングの使用は含みません (以下で取り上げます)。
- モード
- このキャッシュインスタンスが提供できるモードです。
- サポート
- このキャッシュストアインスタンスでサポートされている機能です。
- Locking
- Locking is a mechanism that restricts access to cached data to one process at a time to prevent the data from being overwritten. The locking method determines how the lock is acquired and checked.
- ロッキング
- ロッキングはデータが上書きされないようキャッシュデータへのアクセスを1度に1プロセスのみに制限するためのメカニズムです。ロッキングメソッドはロックの取得および確認方法を決定します。The locking method determines how the lock is acquired and checked.
- Actions
- Any actions that can be performed against this cache store instance.
既知のキャッシュ定義 Known cache definitions
The idea of a cache definition hasn't been discussed here yet. It is something controlled by the developer. When they create a cache they can do so in two ways, the first is by creating a cache definition. This is essentially telling Moodle about the cache they've created. The second way is to create an Adhoc cache. Developers are always encouraged to use the first method. Only caches with a definition can be mapped and further configured by the admin. Adhoc caches will make use of default settings only.
Typically Adhoc caches are only permitted in situations where the cache is small and configuring it beyond defaults would provide no benefit to administrators. Really its like saying you the administrator doesn't need to concern yourself with it.
For each cache shown here you get the following information:
- Definition
- A concise description of this cache.
- Mode
- The cache type this cache is designed for.
- Component
- The code component the cache is associated with.
- Area
- The area of code this cache is serving within the component.
- Store mappings
- The store or stores that will be used for this cache.
- Sharing
- How is sharing configured for this site.
- Actions
- Any actions that can be performed on the cache. Typically you can edit the cache store instance mappings, edit sharing, and purge the cache.
You'll also find at the bottom of this table a link title "Rescan definitions". Clicking this link will cause Moodle to go off an check all core components, and installed plugins looking for changes in the cache definitions.
This happens by default during upgrade, and if a new cache definition is encountered. However should you find yourself looking for a cache that isn't there this may be worth a try.
It is also handy for developers as it allows them to quickly apply changes when working with caches. It is useful when tweaking cache definitions to find what works best.
Information on specific cache definitions can be found on the Cache definitions page.
キャッシュロックインスタンス概要 Summary of cache lock instances
As mentioned above cache locking is an advanced concept in MUC.
The table here shows information on the configured locking mechanisms available to MUC. By default just a single locking mechanism is available, file locking.
At present there are no caches that make use of this and as such I won't discuss it further here.
マッピングが存在しない場合に使用するストア Stores used when no mapping is present
This table quickly shows which cache store instances are going to be used for cache types if there are no specific mappings in place.
To simplify that, this show the default cache stores for each type.
At the bottom you will notice there is a link "Edit mappings" that takes you to a page where you can configure this.
キャッシュストアインスタンスを追加する Adding cache store instances
The default configuration is going to work for all sites, however you may be able to improve your sites performance by making use of various caching backends and techniques. The first thing you are going to want to do is add cache store instances configured to connect to/use the cache backends you've set up.
ファイルキャッシュ File cache
When on the cache configuration screen within the Installed cache stores table you should be able to see the File cache plugin, click `Add instance` to start the process of adding a file cache store instance.
When creating a file cache there is in fact only one required param, the store name. The store name is used to identify the file store instance in the configuration interface and must be unique to the site. It can be anything you want, but we would advice making it something that describes you intended use of the file store.
The following properties can also be specified, customising where the file cache will be located, and how it operates.
- Cache path
- Allows you to specify a directory to use when storing cache data on the file system. Of course the user the webserver is running as must have read/write access to this directory. By default (blank) the Moodledata directory will be used.
- Auto create directory
- If enabled when the cache is initialised if the specified directory does not exist Moodle will create it. If this is specified and the directory does not exist the the cache will be deemed not ready and will not be used.
- Single directory store
- By default the file store will create a subdirectory structure to store data in. The first 3 characters of the data key will be used as a directory. This is useful in avoiding file system limits it the file system has a maximum number of files per directory. By enabling this option the file cache will not use subdirectories for storage of data. This leads to a flat structure but one that is more likely hit file system limits. Use with care.
- Prescan directory
- One of the features the file cache provides is to prescan the storage directory when the cache is first used. This leads to faster checks of files at the expense of an in-depth read.
The file cache store is the default store used for application caches and by default the moodledata directory gets used for the cache. File access can be a taxing resource in times of increased load and the following are some ideas about configuring alternative file stores in order to improve performance.
First up is there a faster file system available for use on your server.
Perhaps you've an SSD installed but are not using it for your moodledata directory because space is a premium.
You should consider creating a directory or small partition on your SSD and creating a file store to use that instead of your Moodle data directory.
Next you've not got a faster drive available for use, but you do have plenty of free space.
Something that may be worth giving a shot would be to create a small partition on the drive you've got installed that uses a performance orientated file system.
Many linux installations these days for example use EXT4, a nice file system but one that has overheads due to the likes of journalling.
Creating a partition and using a file system that has been optimised for performance may give you that little boost you are looking for. Remember caches are designed to be volatile and choosing a file system for a cache is different decision to choosing a file system for your server.
Finally if you're ready to go to lengths and have an abundance of memory on your server you could consider creating a ramdisk/tmpfs and pointing a file store at that.
Purely based in memory, it is volatile exactly like the cache is, and file system performance just isn't going to get much better than this.
Of course you will be limited in space and you are essentially taking that resource away from your server.
Please remember with all of these ideas that they are just ideas.
What ever you choose - test, test, test, be sure of the decision you make.
Memcache
Before you can add a Memcache store instance you must first have a Memcached server you can access and have the Memcache php extension installed and enabled on your web server.
Like the file store you must provide a the store name. It is used to identify the store instance in the configuration interface and must be unique to the site.
For a Memcache store you must also enter the Memcache server, or servers you wish it to make use of.
Servers should be added one per line and each line can contain 1 to 3 properties separated by colons.
- The URL or IP address of the server (required)
- The port the server is listening on (optional)
- The weight to give this server (optional)
For example, if you had two Memcached instances running on your server, one configured for the default port, and one configured for 11212 you would use the following:
127.0.0.1
127.0.0.1:11212
Optionally you can also specify a key prefix to use. What you enter here will prefixed to all keys before accessing the server and can be used to effectively partition the Memcache space in a recognisable way. This can be handy if you have a management tool for you Memcached server that you use to inspect what is stored there.
Important implementation notes
- The Memcache 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 Memcache store within Moodle it deletes ALL entries in the Memcache backend. 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 those servers. Doing so may lead to performance depreciation and adverse affects. - Likewise if you want to use Memcache 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!
Memcached
Like the Memcache store you must first have a Memcached server you can access and have the Memcached php extension installed and enabled on your server.
Also like the Memcache store there are two required parameters in configuring a Memcached store.
- Store name
- It is used to identify the store instance in the configuration interface and must be unique to the site.
- Servers
- The servers you wish this cache store use. See below for details.
Servers should be added one per line and each line can contain 1 to 3 properties separated by colons.
- The URL or IP address of the server (required)
- The port the server is listening on (optional)
- The weight to give this server (optional)
For example, if you had two Memcached instances running on your server, one configured for the default port, and one configured for 11212 you would use the following:
127.0.0.1
127.0.0.1:11212
There are also several optional parameters you can set when creating a Memcached store.
- Use compression
- Defaults to true, but can be disabled if you wish.
- Use serialiser
- Allows your to select which serialiser gets used when communicating with the Memcache server. By default the Memcached extension and PHP only provide one serialised, however there is a couple of others available for installation if you go looking for them. One for example is the igbinary found at https://github.com/igbinary/igbinary.
- Prefix key
- Allows you to set some characters that will be prefixed to all keys before interacting with the server.
- Hash method
- The hash method provided by the Memcached extension is used by default here. However you can select to use an alternative if you wish. http://www.php.net/manual/en/memcached.constants.php provides a little information on the options available. Please note if you wish to you can also override the default hash function PHP uses within your php.ini.
- 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.
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
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
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:
- Moodle performance testing: how much more horsepower do each new versions of Moodle require?
- How to load test your Moodle server using Loadstorm
負荷分散さらたウェブサーバのパフォーマンスに関するアドバイス Performance advice for load-balanced web servers
- 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
- 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 definitions Information on the cache definitions found within Moodle.
- Cache API Details of the Cache API.
- Cache API - Quick reference A short, code focused page of on the Cache API.
- The Moodle Universal Cache (MUC) The original cache specification.
Cache related forum discussions that may help in understanding MUC:
- MUC is here, now what?
- Status of MUC?
- Putting cachedir on local disks in cluster
- moodle cachestore_file
Other:
- Moodle 2.4.5 vs. 2.5.1 performance and MUC APC cache store blog post by Justin Filip
