「キャッシング」の版間の差分

提供：MoodleDocs
移動先:案内、検索
パフォーマンス
 
(同じ利用者による、間の392版が非表示)
1行目: 1行目:
{{Performance}}
{{パフォーマンス}}


作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] ([[利用者・トーク:Mitsuhiro Yoshida|トーク]])
作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] ([[利用者・トーク:Mitsuhiro Yoshida|トーク]])
31行目: 31行目:
Moodleのキャッシングは概観と同じく難しいものではありません。背景の知識を少しだけ学ぶことにより、キャッシュ設定に関して多くを理解することができます。
Moodleのキャッシングは概観と同じく難しいものではありません。背景の知識を少しだけ学ぶことにより、キャッシュ設定に関して多くを理解することができます。


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


最初はアプリケーションキャッシュです。This is by far the most commonly used cache type in code. Its information is shared by all users and its data persists between requests. Information stored here is usually cached for one of two reasons, either it is required information for the majority of requests and saves us a one of more database interactions or it is information that is accessed less frequently but is resource intensive to generate.<br />
最初はアプリケーションキャッシュです。これは現在のところコードで最も一般的に使用されているキャッシュタイプです。この情報はすべてのユーザで共有された上でデータはリクエスト間で保持されます。ここでキャッシュされる情報には通常1または2つの理由があります。その理由は主要なリクエストに必要な情報を私たちのデータベースリクエストのために保存するため、またはアクセス頻度が低いのに関わらず取得に資源への負荷がかかる情報を保存するためです。<br />
By default this information is stored in an organised structure within your Moodle data directory.
この情報はデフォルトであなたのMoodleデータディレクトリ内の組織化された構造に保存されます。


The second cache type is the session cache. This is just like the PHP session that you will already be familiar with, in fact it uses the PHP session by default. You may be wondering why we have this cache type at all, but the answer is simple. MUC provides a managed means of storing, and removing information that is required between requests. It offers developers a framework to use rather than having to re-invent the wheel and ensures that we have access to a controlled means of managing the cache as required.<br />
2番目のキャッシュタイプはセッションキャッシュです。これはあなたがすでに知っているPHPセッションに似ています。実際のところ、デフォルトでPHPセッションを使用しています。あなたはなぜ私たちがこのキャッシュタイプを持っているのか不思議に思うかもしれませんが、答えはシンプルです。MUCは保存のための管理手段を提供た上でリクエスト間で必要な情報を削除します。これは開発者に車輪を再発明せずに使用できるフレームワークを提供して私たちに必要なキャッシュを管理する手段があることを保証します。<br />
Its important to note that this isn't a frequently used cache type as by default session cache data is stored in the PHP session and the PHP session is stored in the database. Uses of the session cache type are limited to small datasets as we don't want to bloat sessions and thus put strain on the database.
デフォルトではセッションキャッシュはPHPセッションに保存されPHPセッションはデータベースで保存されるため、これは頻繁に使用されるキャッシュタイプではないことに留意してください。私たちはセッションを肥大させたくないため、またデータベース負荷をかけたくないため、セッションキャッシュタイプの使用は小さなデータセットに制限しています。


The third and final type is the request cache. Data stored in this cache type only persists for the lifetime of the request. If you're a PHP developer think of it like a managed static variable.<br />
3番目、そして最後のキャッシュタイプはリクエストキャッシュです。このキャッシュタイプに保存されたデータはリクエストの存続時間のみ存続します。あなたがPHP開発者の場合、このキャッシュタイプを管理静的変数のように考えてください。<br />
This is by far the least used of the three cache types, uses are often limited to information that will be accessed several times within the same request, usually by more than area of code.
これは3つのキャッシュタイプの中でも一番使用されるキャッシュタイプです。ほとんどの場合、このキャッシュタイプの使用は同じリクエストの中で数回アクセスされる情報に制限されますが、通常はコードの範囲を超えます。
Cached information is stored in memory by default.
キャッシュされた情報はデフォルトでメモリに保存されます。


==== キャッシュタイプおよび複数サーバシステム Cache types and multiple-server systems ====
==== キャッシュタイプおよび複数サーバシステム ====


If you have a system with multiple front-end web servers, the application cache must be shared between the servers. In other words, you cannot use fast local storage for the application cache, but must use shared storage or some other form of shared cache such as a shared memcache.
あなたのシステムが複数フロントエンドのウェブサーバの場合、アプリケーションキャッシュをサーバ間で共有してください。言い換えれば、あなたは速いローカルストレージをアプリケーションキャッシュに使用することはできません。共有ストレージまたは共有memcacheのような形の共有キャッシュを使用してください。


The same applies to session cache, unless you use a 'sticky sessions' mechanism to ensure that within a session, users always access the same front-end server.
あなたが「スティッキーセッション」メカニズムを使用してユーザが常に同じフロントエンドサーバにアクセスすることを確実にしない限り、セッションキャッシュにも同じ内容が適用されます。


===キャッシュバックエンド Cache backends===
===キャッシュバックエンド===
Cache backends are where data actually gets stored. These include things like the file system, php session, Memcached, and memory.<br />
キャッシュバックエンドは実際にデータが保存される場所です。これにはファイルシステム、phpセッション、Memcachedおよびメモリのようなものを含みます。<br />
By default just file system, php session, and memory are used within Moodle.<br />
デフォルトではMoodle内でファイルシステム、phpセッションおよびメモリが使用されます。<br />
We don't require that a site has access to any other systems such a Memcached. Instead that is something you are responsible for installing and configuring yourself.<br />
私たちはMemcachedのような他のシステムによるサイトへのアクセスを必要としません。代わりにあなた自身の責任で何か他のものをインストールおよび設定してください。<br />
When cache backends are mentioned think of systems outside of Moodle that can be used to store data. The MongoDB server, the Memcache server and similiar "server" applications.
キャッシュのバックエンドが言及された場合、データの保存に使用されているMoodle外部のシステムのことを考えてください。MongoDBサーバ、Memcacheサーバおよび類似の「サーバ」アプリケーション。


===キャッシュストア Cache stores===
===キャッシュストア===


Cache stores are a plugin type within Moodle. They facilitate connecting Moodle to the cache backends discussed above. The standard Moodle has the three defaults mentioned above as well as Memcache, Memcached, MongoDB, [[APC user cache (APCu)|APC user cache (APCu)]] and [[Redis cache store|Redis]].
キャッシュストアはMoodleのプラグインタイプです。これは前述のキャッシュバックエンドとMoodleの接続をサポートします。標準的なMoodleには前述のMemcache、Memcached、MongoDB、[[APCユーザキャッシュ (APCu)|APCユーザキャッシュ (APCu)]]および[[Redisキャッシュストア|Redis]]に加えて3つのデフォルトがあります


You can find other cache store plugins in the [https://moodle.org/plugins/browse.php?list=category&id=48 plugins database].
あなたは他のキャッシュストアプラグインを[https://moodle.org/plugins/browse.php?list=category&id=48 プラグインデータベース]で探すことができます。


The code for these is located within cache/stores in your Moodle directory root.
これらのコードはあなたのMoodleのルートディレクトリ内cache/storesにあります。


Within Moodle you can configure as many cache stores as your architecture requires. If you have several Memcache servers for instance you can create an cache store instance for each. Moodle by default contains three cache store instances that get used when you've made no other configuration.
あなたのアーキテクチャに必要とするだけのキャッシュストアを設定することができます。いくつかのMemcacheサーバがある場合、あなたはそれぞれにキャッシュストアインスタンスを作成することができます。あなたが他に設定しない場合に使用されるキャッシュストアインスタンスがMoodleにはデフォルトで3種類あります。
* A file store instance is created which gets used for all application caches. It stores its data in your moodledata directory.
* すべてのアプリケーションキャッシュとして使用するためファイルストアインスタンスが作成されます。ファイルストアインスタンスはあなたのmoodledataディレクトリにデータを保存します。
* A session store instance is created which gets used for all session caches. It stores its data in the PHP session, which by default is stored if your database.
* セッションストアインスタンスはすべてのセッションキャッシュに使用するため作成されます。
* A static memory store instance is created which gets used for all request cache types. Data exists in memory for just the lifetime of a request.
* スタティックメモリストアインスタンスはすべてのリクエストキャッシュタイプに使用するため作成されます。メモリ内のデータはリクエストの存続期間のみ存在します。


===キャッシュ: コード内では何が起きているのか Caches: what happens in code===
===キャッシュ: コード内では何が起きているのか===
Caches are created in code and are used by the developer to store data they see a need to cache.<br />
キャッシュはコード内で作成され、開発者が確認する必要のあるデータを保存するため使用されます。<br />
Lets keep this section nice and short because perhaps you are not a developer. There is one very important point you must know about.<br />
恐らく、あなたは開発者ではないでしょうから、このセクションで分かりやすく簡単に説明してみましょう。あなたが知るべき非常に重要なことが１点あります。
The developer does not get any say in where the data gets cached. They must specify the following information when creating a cache to use.
# The type of cache they require.
# The area of code this cache will belong to (the API if you will).
# The name of the cache, something they make up to describe in one word what the cache stores.


There are several optional requirements and settings they can specify as well, but don't worry about that at this point.<br />
開発者はデータがどこにキャッシュされるかに関して知ることはありません。使用するキャッシュを作成する場合、開発者は以下の情報を指定する必要があります。
The important point is that they can't choose which cache backend to use, they can only choose the type of cache they want from the three detailed above.
# 必要なキャッシュタイプ
# このキャッシュが属するコードのエリア (あなたがAPIを使用する場合はAPI)
# キャッシュ名 (キャッシュが何に使われるのか表した単語)


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


This is best described in relation to roles played in an organisation.
===どのようにして繋ぎ合せるのか===


# The system administrator installs the cache backends you wish to use. Memcache, XCache, APC and so on.<br />Moodle doesn't know about these, they are outside of Moodle's scope and purely the responsibility of your system administrator.
以下、組織内でのロールに関して説明します。
# The Moodle administrator creates a cache store instance in Moodle for each backend the site will make use of.<br />There can be one or more cache stores instances for each backend. Some backends like Memcached have settings to create separated spaces within one backend.
# The developer has created caches in code and is using them to store data.<br />He doesn't know anything about how you will use your caches, he just creates a "cache" and tells Moodle what type it is best for it.
# The Moodle administrator creates a mapping between a cache store instance and a cache.<br />That mapping tells Moodle to use the backend you specify to store the data the developer wants cached.


In addition to that you can take things further still.
# システム管理者はあなたが使用したいMemcache、XCache、APCのようなキャッシュバックエンドをインストールします。<br />Moodleはこれらに関して知りません。これらはMoodleの範囲外であり、純粋にあなたのシステム管理者に責任があります。
* You can map many caches to a single cache store instance.
# それぞれのバックエンドがサイトで利用できるようMoodle管理者がキャッシュストアインスタンスを作成します。<br />それぞれのバックエンドには1つまたはそれ以上のキャッシュストアを置くことができます。Memcachedのようなバックエンドには1つのバックエンド内に複数の別々のスペースを作成できる設定があります。
* You can map multiple cache store instances to a single cache with priority (primary ... final)
# 開発者はコード内でキャッシュを作成して、それをデータ保存のために使用します。<br />開発者はあなたがキャッシュをどのように使用するか知りません。開発者はキャッシュを作成して、最適なキャッシュタイプをMoodleに伝えるのみです。
* You can map a cache store instance to be the default store used for all caches of a specific type that don't otherwise have specific mappings.
# Moodle管理者はキャッシュストアとキャッシュ間のマッピングを作成します。<br />そのマッピングは開発者がキャッシュしたいデータを保存するため、あなたが指定したバックエンドを使用するようMoodleに伝えます。


If this is the first time you are reading about the Moodle Universal Cache this probably sounds pretty complex but don't worry it will be discussed in better detail as we work through how to configure the caching in Moodle.
加えて、あなたはさらに以下のことができます。
* あなたは多くのキャッシュを単一のキャッシュストアインスタンスにマッピングすることができます。
* あなたは複数のキャッシュストアインスタンスを単一のキャッシュに優先度 (最初... 最後) を付けてマッピングすることができます。
* あなたは特定のマッピングを持たないタイプのキャッシュすべてに使用されるデフォルトストアとしてキャッシュストアインスタンスをマッピングすることができます。


==高度な概念 Advanced concepts==
これがあなたにとってMoodleユニバーサルキャッシュに関して資料を読むことが最初である場合、非常に複雑に思えるかもしれませんが心配しないでください。私たちはMoodle内でのキャッシング設定に取り組むため、Moodleユニバーサルキャッシュの詳細に関して取り上げます。
These concepts are things that most sites will not need to know or concern themselves about.


You should only start looking here if you are looking to maximise performance on large sites running over clustered services with shared cache backends, or on multi-site architecure again where information is being shared between sites.
==高度な概念==
これらの概念は多くのサイトでは知る必要のない、または関わる必要のないものです。


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


The idea of locking is nothing new, it is the process of controlling access in order to avoid concurrency issues.
===ロッキング ===


MUC has a second type of plugin, a cache lock plugin that gets used when caches require it. To date no caches have required it. A cache by nature is volatile and any information that is absolutely mission critical should be a more permanent data store likely the database.
ロッキングのアイデアに新しいものは何もありません。ロッキングは並列問題を避けるためアクセスをコントロールする処理です。


Nonetheless there is a locking system that cache definitions can require within their options and that will be applied when interacting with a cache store instance.
MUCは2つ目のタイプのプラグインであり、ロックが必要な場合に使用されるキャッシュロックプラグインです。今までキャッシュを必要としませんでした。元来、キャッシュは不安定なものであり、極めて重要なデータはデータベースのような永続的なデータストアに保存すべきです。


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


Every bit of data that gets stored within a cache has a calculated unique key associated with it.<br />
===共有===
By default part of that key is the site identifier making any content stored in the cache specific to the site that stored it. For most sites this is exactly what you want.<br />
However in some situations its beneficial to allow mutiple sites, or somehow linked sites to share cached data.<br />
Of course not all caches can be shared, however some certainly can and by sharing you can further reduce load and increase performance by maximising resource use.


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


To make use of sharing you need to first configure identical cache store instances in the sites you want to share information, and then on each site set the sharing for the cache to the same value.
これは高度な機能であり、あなたが共有を選択する場合は注意して設定してください。


; Sites with the same site ID : This is the default, it allows for sites with the same site ID to share cached information. It is the most restrictive but is going to work for all caches. All other options carry an element of risk in that you have to ensure the information in the cache is applicable to all sites that will be accessing it.
共有を使用する場合、あなたは最初に情報を共有したいサイトのキャッシュストアインスタンスを同一に設定する必要があります。それぞれのサイトでキャッシュの共有を同一の設定値に設定してください。
; Sites running the same version : All sites accessing the backend that have the same Moodle version can share the information this cache has stored in the cache store.
; Custom key : For this you manually enter a key to use for sharing. You must then enter the exact same key into the other sites you want to share information.
; Everyone : The cached data is accessible to all other sites accessing the data. This option puts the ball entirely in the Moodle administrators court.


As an example if you had several Moodle sites all the same version running on server with APC installed you could decide to map the language cache to the APC store and configure sharing for all sites running the same version.<br />
; 同じサイトIDのサイト : これはデフォルトです。キャッシュ情報を共有するため同じサイトIDのサイトが許可されます。これは最も制限のあるものですがすべてのキャッシュで動作します。他のオプションにはリスク要因があるため、アクセス可能なサイトすべてにおいてキャッシュ情報を利用できることを確実にしてください。
The language cache for sites on the same version is safe to share in many situations, it is used on practically every page, and APC is extremely fast. These three points may result in a nice wee performance boost for your sites.<br />
; 同じバージョンで動作しているサイト : バックエンドにアクセスする同じバージョンのMoodleサイトすべてはキャッシュストアに保存されたキャッシュ情報を共有することができます。
It is important to consider with the language cache that by sharing it between sites any language customisations will also be shared.
; カスタムキー : あなたはここに共有に使用するキーを手動で入力することができます。あなたが情報を共有したい他のサイトに全く同じキーを入力してください。
; 誰でも: キャッシュ済みデータにはデータにアクセスできる他のサイトすべてからアクセスすることができます。このオプションでは一連のMoodle管理者にすべての権限を与えます。


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


The cache configuration screen is your one stop shop for configuring caching in Moodle.<br />
==キャッシュ設定画面==
It gives you an overview of how caching is currently configured for your site and it provides links to all of the actions you can perform to configure caching to your specific needs.


===キャッシュ設定画面にアクセスする Accessing the cache configuration screen===
あなたはキャッシュ設定でMoodleのキャッシングに関するすべてを設定することができます。<br />
ここではあなたのサイトの現在の設定がどのようにされているのか概要を示します。また、あなたの必要に応じて設定するための操作のリンクすべてが提供されます。


[[Image:cacheadmin29.png|thumb|500px|The cache configuration screen]]
===キャッシュ設定画面にアクセスする===


The cache configuration screen can only be accessed by users with the ''moodle/site:config'' capability. By default this is only admins.<br />
[[Image:cacheadmin29.png|thumb|500px|キャッシュ設定画面]]
Once logged in the configuration screen can be found in  '''Site Administration > Plugins > Caching > Configuration'''.


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


[[Image:ist29.png|thumb|500px|Installed cache stores screenshot]]
===キャッシュストアをインストールする===


This is showing you a list of cache store plugins that you have installed.<br />
[[Image:ist29.png|thumb|500px|インストール済みキャッシュストアスクリーンショット]]
For each plugin you can quickly see whether it is ready to be used (any php requirements have been met), how many store instances already exist on this site, the cache types that this store can be used for, what features it supports (advanced) and any actions you can perform relating to this store.


Often the only action available is to create a new store instance.<br />
ここではあなたがインストールしたキャッシュストアプラグインを一覧表示しています。<br />
Most stores support having multiple instances, however not all as you will see that that the session cache and static request cache do not. For those two stores it does not make sense to have multiple instances.
あなたはそれぞれのプラグインを使用できるかどうか (すべてのPHP要件に合致しているか)、このサイトですでにいくつのストアインスタンスが存在するか、このストアが使用できるキャッシュタイプ、サポートされる (高度な) 機能およびこのストアに関連して実行できる操作を素早く確認することができます。


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


[[Image:csi29.png|thumb|500px|Configured store instances screenshot]]
===設定済みストアインスタンス===


Here you get a list of the cache store instances on this site.
[[Image:csi29.png|thumb|500px|設定済みストアインスタンスのスクリーンショット]]


; '''Store name''' : The name given to this cache store instance when it is created so that you can recognise it. It can be anything you want and is only used so that you can identify the store instance.
以下、このサイトであなたが取得できるキャッシュストアの一覧です。
; '''Plugin''' : The cache store plugin of which this is an instance of.
; '''Ready''' : A tick gets shown when all PHP requirements have been met as well as any connection or set-up requirements have been verified.
; '''Store mappings''' : The number of caches this store instance has been mapped to explicitly. Does not include any uses through default mappings (discussed below).
; '''Modes''' : The modes that this cache store instance can serve.
; '''Supports''' :  The features supported by this cache store instance.
; '''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.
; '''Actions''' : Any actions that can be performed against this cache store instance.


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


[[Image:caching-27-04-known-cache-definitions.png|thumb|500px|Known cache definitions screenshot]]
===既知のキャッシュ定義===


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.<br />
[[Image:caching-27-04-known-cache-definitions.png|thumb|500px|既知のキャッシュ定義スクリーンショット]]
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:
ここではキャッシュ定義のアイデアはまだ考察されていません。これは管理者によって管理されるものです。開発者がキャッシュを作成する場合、2つの方法があります。最初の方法ではキャッシュ定義を作成します。これは基本的にどのようなキャッシュを作成したのかMoodleに伝えます。2番目の方法はアドホック (Adhoc 限定目的) のキャッシュを作成することです。開発者は常に最初の方法を取ることをお勧めします。定義のあるキャッシュのみマップできます。また、定義のあるキャッシュのみさらに管理者が設定できます。アドホックキャッシュはデフォルト設定のみ使用します。 <br />
通常、アドホックキャッシュはキャッシュが小さい場合のみ許可されます。アドホックキャッシュのサイズがデフォルトより大きくなった場合、管理者に利点はありません。これは管理者にあなたのキャッシュに関わらないでくださいと言っているようなものです。


; '''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.<br />
; '''定義''' : キャッシュに関する簡単な説明です。
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.<br />
; '''モード''' : このキャッシュのキャッシュタイプです。
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.
あなたにはこのテーブルの最下部に「定義を再スキャンする」リンクが表示されます。このリンクをクリックすることにより、Moodleがすべてのコンポーネントおよびインストール済みプラグインをチェックしてキャッシュ定義の変更点を探します。しかし、あなたがそこにないキャッシュを探すのでしたら、試してみる価値はあります。<br />


===キャッシュロックインスタンス概要 Summary of cache lock instances===
また、開発者がキャッシュで作業する場合、変更点をすぐに提供できる点も便利です。キャッシュ定義を調整する時にどの設定が最良であるか探す場合も便利です。


[[Image:caching-27-05-summary-of-cache-lock-instances.png|thumb|500px|Summary of cache lock instances screenshot]]
特定のキャッシュ定義に関する情報は[[キャッシュ定義]]ページをご覧ください。


As mentioned above cache locking is an advanced concept in MUC.<br />
===キャッシュロックインスタンス概要===
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===
[[Image:caching-27-05-summary-of-cache-lock-instances.png|thumb|500px|キャッシュロックインスタンス概要のスクリーンショット]]


[[Image:caching-27-06-stores-used-when-no-mapping-is-present.png|thumb|500px|Mapping of default stores screenshot]]
上で言及したようにキャッシュロッキングはMUCの高度な概念です。<br />
ここでテーブルはMUCで利用可能なロッキングメカニズムの設定情報を表示します。デフォルトでは次の単一のロッキングメカニズムのみ利用できます: ファイルロッキング
現在、これを使用しているキャッシュは存在しないため、これ以上ここで説明しません。


This table quickly shows which cache store instances are going to be used for cache types if there are no specific mappings in place.<br />
===マッピングが存在しない場合に使用するストア===
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.
[[Image:caching-27-06-stores-used-when-no-mapping-is-present.png|thumb|500px|デフォルトストアマッピングのスクリーンショット]]


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


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===
==キャッシュストアインスタンスを追加する==


[[Image:caching-27-07-add-file-cache-store.png|thumb|300px|Adding a file cache store screenshot]]
デフォルト設定はすべてのサイトで動作します。しかし、あなたのサイトのパフォーマンスを多様なキャッシュバックエンドおよび技術により改善することができます。あなたが取り組みたい最初のことはセットアップしたキャッシュバックエンドに接続するため設定されたキャッシュストアインスタンスを追加することでしょう。


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.
[[Image:caching-27-07-add-file-cache-store.png|thumb|300px|ファイルキャッシュストア追加のスクリーンショット]]
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.
ファイルキャッシュを作成する場合、実際のところ、必須パラメータはストア名1つのみです。ストア名は設定インターフェースでファイルストアインスタンスを認識するために使用されます。ストア名はサイト内でユニークである必要があります。
; '''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.<br />
; '''キャッシュパス''' : あなたはファイルシステムへのキャッシュデータ保存時に使用するディレクトリを指定できます。もちろん、ウェブサーバのユーザにはこのディレクトリへの読み書き権が必要です。デフォルト (空白) ではMoodleデータディレクトリが使用されます。
Perhaps you've an SSD installed but are not using it for your moodledata directory because space is a premium.<br />
; '''自動ディレクトリ作成 ''' : この設定を有効にした場合、キャッシュ作成時に指定されたディレクトリが存在しない場合にMoodleは自動的にディレクトリを作成します。ディレクトリが指定されて存在しない場合、キャッシュは準備できていないと見なされ使用されません。
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.
; '''単一ディレクトリストア''' : デフォルトではファイルストアはデータを保存するためサブディレクトリ構造を作成します。データキーの最初の3文字はディレクトリ名に使用されます。これはディレクトリあたりの最大ファイル数を持つファイルシステムの制限を回避するため有用です。このオプションを有効にした場合、ファイルキャッシュはデータの保存にサブディレクトリを使用しません。これによりフラットな構造になりますが、ファイルシステムの制限に達する可能性があります。使用には注意してください。
; '''ディレクトリを事前スキャンする''' : ファイルキャッシュが提供する機能の1つにキャッシュ初回使用時のストレージディレクトリの事前スキャンがあります。これにより詳細な読み込みを犠牲にすることでファイルを素早くチェックできます。


Next you've not got a faster drive available for use, but you do have plenty of free space.<br />
ファイルキャッシュストアはアプリケーションキャッシュに使用されるデフォルトのストアです。また、デフォルトではmoodledataディレクトリがキャッシュに使用されます。
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.<br />
サーバ負荷が増えた場合、ファイルアクセスに負担がかかる場合があります。以下、パフォーマンスを改善するための代替ファイルストアの設定に関するアイデアです。
Many linux installations these days for example use EXT4, a nice file system but one that has overheads due to the likes of journalling.<br />
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.<br />


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.
まず最初にあなたのサーバで利用可能な速いファイルシステムを設置してください。<br />
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.<br />
恐らく、あなたはMoodleをSSDにインストールしていると思いますが、ディスクスペースが高額になるため、moodledataディレクトリはSSDに設置されていないことでしょう。<br />
Of course you will be limited in space and you are essentially taking that resource away from your server.
あなたのSSDにディレクトリまたは小さなパーティションを作成して、そこでMoodleデータディレクトリの代わりに使用するファイルストアを作成することを考慮してください。


Please remember with all of these ideas that they are just ideas.<br />
次にあなたに利用できる速いドライブがない場合、かつ多くの空き容量がある場合を考えます。<br />
What ever you choose - test, test, test, be sure of the decision you make.
ドライブに小さなパーティションを作成して、パフォーマンス重視のファイルシステム設定を試してみても良いでしょう。<br />
例えば昨今の多くのLinuxインストレーションではEXT4を使用しています。EXT4は素晴らしいファイルシステムですがジャーナリングのような機能が影響してオーバーヘッドが生じてしまいます。<br />
パーティションを作成してパフォーマンスのために最適化されたファイルシステムを使用することにより、あなたが探していたものに近付くことでしょう。キャッシュは揮発性であることを念頭に設計されている点、またキャッシュのためのファイルシステムの選択はあなたのサーバのファイルシステムの選択とは異なる点に留意してください。<br />
 
最後にあなたに十分な時間とサーバに十分なメモリがある場合、ramdisk/tmpfsを作成して、そこにファイルストアを指定することを考慮してください。
純粋にメモリをベースとした場合、キャッシュのように厳密に揮発性となり、ファイルシステムパフォーマンスはこれより良くなることはありません。<br />
もちろん、あなたはスペースを制限してそのリソースをサーバから取り除くことができます。
 
これらのアイデアは単にアイデアであることに留意してください。<br />
あなたがどのような選択をしたとしても - テスト、テスト、テストをして、あなたの決定が正しいことを確認してください。


===Memcache===
===Memcache===


[[Image:caching-27-08-add-memcache-store.png|thumb|300px|Add Memcache store screenshot]]
[[Image:caching-27-08-add-memcache-store.png|thumb|300px|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.
Memcacheストアインスタンスを追加できるようにしたい場合、最初にあなたがアクセスできるMemecachesサーバを準備して、ウェブサーバでMemcache php拡張モジュールをインストールおよび有効化する必要があります。


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.<br />
あなたはファイルストアのようにストア名を指定する必要があります。これは設定インスタンス内でストアインスタンスを識別するため使用されます。また、サイトでユニークである必要があります。<br />
For a Memcache store you must also enter the Memcache server, or servers you wish it to make use of.
Memcacheストアの場合、あなたはMemcacheサーバを指定するか、Memcacheを使用するサーバを指定する必要があります。
Servers should be added one per line and each line can contain 1 to 3 properties separated by colons.
サーバは1行あたり1台を記述してください。それぞれの行にはコロンで分けられた１つから3つのプロパティを含んでください。
# The URL or IP address of the server (required)
# サーバのURLまたはIPアドレス (必須)
# 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:
例えば、あなたのサーバで2つのMemcachedインスタンスが動作している場合を考えます。1つの設定をデフォルトポート、もう1つの設定を11212にしたい場合、次のようになります。
<code>
<code>
127.0.0.1
127.0.0.1
264行目: 265行目:
</code>
</code>


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


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


===Memcached===
===Memcached===


[[Image:caching-27-09-add-memcached-store.png|thumb|300px|Add Memcached store screenshot]]
[[Image:caching-27-09-add-memcached-store.png|thumb|300px|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.
最初にMemcacheストアと同様にあなたがアクセスできるMemcachedサーバを持つ必要があります。同時にあなたのサーバでMemcached PHP拡張モジュールをインストールおよび有効化する必要もあります。


Also like the Memcache store there are two required parameters in configuring a Memcached store.
また、MemecachedストアにはMemecacheストアのように設定に2つの必須パラメータがあります。


; '''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.
サーバは1行あたり1台を追加してください。それぞれの行にはコロンで分けられた1～3つのプロパティを記述できます。
# The URL or IP address of the server (required)
# サーバのURLまたはIPアドレス (必須)
# 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:
例えば、あなたのサーバに2つのMemcachedインスタンスが動作しているとします。1つはデフォルトポート、もう1つはポート11212が設定されている場合、次のような設定になります:
<code>
<code>
127.0.0.1
127.0.0.1
293行目: 294行目:
</code>
</code>


There are also several optional parameters you can set when creating a Memcached store.
Memcachedストアを作成する場合、あなたが設定できるいくつかの任意のパラメータがあります。


; '''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.
; '''シリアライザを使用する''' : Memecacheサーバと通信する場合、あなたが使用するシリアライザを選択できるようにします。デフォルトではMemcached拡張モジュールおよびPHPで1つのシリアライザのみ提供できます。しかし、インストレーションに利用できる他のいくつかの方法もあります。1つの例として、igbinary (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.
; '''ハッシュメソッド''' : 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.<br />
* Memcached拡張モジュールでは一連のエントリの削除手段を提供しません。単一エントリが削除されるか、エントリすべてが削除されます。<br />
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.<br />
このため、あなたがMoodle内のMemecacheストアを削除する場合、Memcachedサーバ内のエントリすべてが削除されることに留意してください。これはMoodleだけに関係することではありません。<br />
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.
この理由のため、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!


===MongoDB===
===MongoDB===


[[Image:caching-27-10-add-mongodb-store.png|thumb|300px|Add MongoDB store screenshot]]
[[Image:caching-27-10-add-mongodb-store.png|thumb|300px|MongoDBストアを追加する スクリーンショット]]


MongoDB is an open source document orientated NoSQL database. Check out their website www.mongodb.org for more information.
MongoDBはオープンソースのドキュメント指向データベースです。 詳細はMongoDBの公式サイトをご覧ください: www.mongodb.org


; '''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.
; '''レプリカセット''' : 接続先のレプリカセット名です。これが提供された場合、シード時に「ismaster」データベースコマンドを使用してマスターが決定されます。結果として、ドライバはリストにないサーバであっても接続できます。
; '''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.
; '''使用''' : この設定を有効にした場合、追加、取得および削除処理中にusesafeオプションが使用されます。あなたがレプリカセットを指定した場合、これが強制されます。
; '''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.
; '''拡張キーを使用する''' : この設定を有効にした場合、完全なキーセットがプラグイン連携時に使用されます。これは内部的には使用されませんが、あなたは必要に希望に応じて簡単にMongoDBプラグインを手動で検索および調査できます。この設定を有効にした場合、少しだけ負荷が掛かるため、必要な場合のみ有効にしてください。


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


[[Image:caching-27-11-store-mapping.png|thumb|300px|Cache definition store mapping screenshot]]
[[Image:caching-27-11-store-mapping.png|thumb|300px|キャッシュ定義ストアマッピング (スクリーンショット)]]


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.
ストアインスタンスをキャッシュにマッピングすることにより、キャッシュとやりとりする時にそのストアインスタンスを使うようMoodleに伝えます。これによりMoodle管理者は情報が保存される場所をコントロールできます。また、何よりもまず、あなたのサイトで利用可能なリソースを最大限活用することにより、パフォーマンスを最適化できます。


To set a mapping first browse to the cache configuration screen.<br />
マッピングを設定するには最初にキャッシュ設定画面を閲覧してください。<br />
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.<br />
あなたは表示される画面でこのキャッシュで使用するため1つまたはそれ以上のキャッシュストアインスタンスをマップできます。<br />
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.
あなたは表示されたいくつかのドロップダウンメニューで1つまたはそれ以上のキャッシュをマップできます。マップされたキャッシュすべては相互に情報をやりとりします。「主」ストアはキャッシュとのやりとりの最初に使われるキャッシュです。
The "Final" mapped store will be the last cache store interacted with.<br />
「最終」マップストアは情報をやりとりする最後のキャッシュです。<br />
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.
; ''キャッシュからデータを取得する'' : Moodleはキャッシュにデータを取得するよう依頼します。キャッシュはストアからデータの取得を試みます。ストアにデータが存在する場合、ストアはMoodleで使用できるようキャッシュにデータを渡します。ストアにデータが存在しない場合、「fail」が戻されてMoodleはデータを生成しなければなりません。そして、殆どの場合、生成したデータをキャッシュに送ります。
; ''Storing data in the cache'' : Moodle will ask the cache to store some data, and the cache will give it to the cache store.
; ''キャッシュにデータを保存する'' : Moodleはキャッシュにデータを保存するよう依頼します。そして、キャッシュはデータをキャッシュストアに渡します。


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.
; ''ストアからデータを取得する'' : Modleはキャッシュにデータを取得するよう依頼します。キャッシュは最初のストアからのデータ取得を試みます。最初のストアがデータを取得した場合、ストアはキャッシュにデータを戻してキャッシュはデータをMoodleに戻します。最初のストアにデータがない場合、2番目のストアからのデータ取得を試みます。2番目のストアにデータがある場合、最初のストアにデータを戻してデータをキャッシュに戻す前に保存します。そうでない場合、次のストアが使用されます。これはデータが見つからなくなるか、チェックするストアがなくなるまで続きます。
; ''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.
; ''キャッシュにデータを保存する'' : Modleはキャッシュにデータを保存するよう依頼します。キャッシュは保存のためにすべてのマップ済みキャッシュストアにデータを渡します。


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:
以下、複数ストアのマッピングが利点を提供できる例です:
<pre>
<pre>
Scenario:
シナリオ:
You have have a web server that has a Moodle site as well as other sites.
あなたにはMoodleサイトおよび他のサイトが設置されたウェブサーバがあります。
You also have a Memcache server that is used by several sites including Moodle.
また、あなたはMoodleを含む複数のサイトで使用されるMemcacheサーバがあります。
 
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.
Memcacheはサイズ制限のあるキャッシュです。キャッシュがフルの時にさらに情報ツリーのスペースを要求された場合、最も使われていないキャッシュを削除してスペースが空けられます。
Memcacheが速いため、あなたのMoodleサイトに使いたいと思います。しかし、Memcacheサーバが過度に使用されているため、頻繁にキャッシュ喪失を経験することに気が付きます。


Solution:
ソリューション:
To get around this you map two stores to caches you wish to use Memcache.
この問題を回避するため、あなたが使用したいMemcacheのキャッシュの2つのストアをマップします。
You make Memcache the primary store, and you make the default file store the final cache store.
あなたはMemcacheを主ストアにします。また、デフォルトファイルストアを最終キャッシュストアにします。


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.
これを実現するため、あなたは冗長を作成しました。何かがMoodleにリクエストする場合、最初にMemcache (最速のストア) から取得を試みます。そこにない場合、ファイルキャッシュを確認します。
</pre>
</pre>


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==
* 複数キャッシュをマップすることでオーバーヘッドが増大します。キャッシュのマップが増えるほどオーバーヘッドも増大します。
* あなたがマップするキャッシュストアを考えてみましょう。設定されたデータがキャッシュに保持されたままになった場合、それ以上、ストアをマップできなくなります。このテクニックは主に設定された後のデータの保持が保証されない場合に価値があります。
* 常にあなたの設定をテストしてください。パフォーマンス情報の表示を有効にして、どのストアがキャッシュを動作させるような方法でMoodleとの情報のやり取りに使用されるか確認してください。


[[Image:caching-27-12-default-store-mapping.png|thumb|300px|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.
[[Image:caching-27-12-default-store-mapping.png|thumb|300px|マッピングが存在しない場合に使用されるストアに関する設定スクリーンショット]]
これは特定のマッピングが存在しない場合にキャッシュタイプに使用されるデフォルトストアの実際の設定です。


To set a mapping first browse to the cache configuration screen.<br />
マッピングを設定するには最初にキャッシュ設定画面を表示してください。<br />
Proceed to find the ''Stores used when no mapping is present'' table.<br />
「マッピングが存在しない場合に使用されるストア」テーブルを探してください。<br />
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.
関連するタイプのキャッシュが初期化された場合、あなたにはそれぞれのキャッシュタイプに使用できる1つのストアを選択できる画面が表示されます。これには明示的なマッピングはありません。


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.<br />
すべてのインスタンスを表示する必要はありません。あなたに表示しないストアインスタンスがある場合、存在する「すべて」のキャッシュ定義は適切ではありません。<br />
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==
==あなたのサイトのキャッシングを設定する 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.
このドキュメントを読んでキャッシュの設定に関して1つまたは2つを学べた場合、ここに追加することであなたの学びを共有してください。


* 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.
* キャッシュバックエンドを判断する場合、メリットおよびデメリットを十分に考えてください。メリットおよびデメリットを考える場合、あなたのサイトのことを留意してください。あなたのサイトによりますが、1つのキャッシュバックエンドだけではサイト全体の要求を満たすことができず、自由に複数のバックエンドを持つことにより利益を享受できる場合もあります。
* 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.<br />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.
* 通常、キャッシュバックエンドのインストールおよび使用のように簡単ではありません。キャッシングに関して設定および最適化に注意を払ってください。キャッシングを別の場所でテストした後、Moodleに伝える前にパフォーマンスに関して理解してください。あなたはキャッシュによりデータベースの負荷を軽減してページリクエスト処理を削減できます。The cache allows you to shift load off the database and reduce page request processing.<br />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.<br />Cache definitions have been documented [[Cache definitions]].
* 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.<br />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.<br />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.<br />Cache definitions have been documented [[Cache definitions]].

2019年10月25日 (金) 15:10時点における最新版


作成中です - 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. 必要なキャッシュタイプ
  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台を記述してください。それぞれの行にはコロンで分けられた１つから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
正当な理由でデフォルトでは無効にされています。バッファ書き込みを有効にすることにより、I/O処理をバッファしてMemcachedサーバとの通信を最小限にします。これに関する不都合な点は並列処理のシステムの場合、誰も最初のリクエスト時にデータをMemdadhesサーバにプッシュしないため、結局のところ複数のリクエストによりデータが生成されてしまうことです。この設定を有効にする利点はケイパビリティによってアクセスをコントロールされたエリアをキャッシュできることです。例えばネットワークリソース等に負荷の掛かる多重インタラクションが発生する場合です。しかし、これは結局のところ、スケールの最後の極端な調整と言えます。

重要な実装メモ

  • Memcached拡張モジュールでは一連のエントリの削除手段を提供しません。単一エントリが削除されるか、エントリすべてが削除されます。

このため、あなたがMoodle内のMemecacheストアを削除する場合、Memcachedサーバ内のエントリすべてが削除されることに留意してください。これはMoodleだけに関係することではありません。
この理由のため、Memcached専用サーバの使用を強くお勧めします。同時に同じサーバで他のソフトウェアを動作させないでください。多くのソフトウェアを動作させることにより、結果としてパフォーマンスの低下および好ましくない影響が生じる可能性があります。1つはセッションのため、もう1つはキャッシングのためです。そうでない場合、Moodleのキャッシュ削除があなたのセッションを削除します!

MongoDB

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

MongoDBはオープンソースのドキュメント指向データベースです。 詳細はMongoDBの公式サイトをご覧ください: www.mongodb.org

ストア名
設定インターフェース内でのストアインスタンスの識別のために使用されます。また、サイトでユニークである必要があります。
サーバ
これはあなたが使用したいサーバのための接続ストリングです。複数のサーバはカンマ区切りの一覧で指定できます。
データベース
使用するデータベースのデータベース名です。
ユーザ名
接続時に使用するユーザ名です。
パスワード
接続時に使用するユーザのパスワードです。
レプリカセット
接続先のレプリカセット名です。これが提供された場合、シード時に「ismaster」データベースコマンドを使用してマスターが決定されます。結果として、ドライバはリストにないサーバであっても接続できます。
使用
この設定を有効にした場合、追加、取得および削除処理中にusesafeオプションが使用されます。あなたがレプリカセットを指定した場合、これが強制されます。
安全値を使用する
あなたは安全に使用するため特定の値を提供できます。これは完了したと見なされる前に処理を完了しなければならないサーバ数を決定します。
拡張キーを使用する
この設定を有効にした場合、完全なキーセットがプラグイン連携時に使用されます。これは内部的には使用されませんが、あなたは必要に希望に応じて簡単にMongoDBプラグインを手動で検索および調査できます。この設定を有効にした場合、少しだけ負荷が掛かるため、必要な場合のみ有効にしてください。

ストアインスタンスにキャッシュをマッピングする

ファイル:caching-27-11-store-mapping.png
キャッシュ定義ストアマッピング (スクリーンショット)

ストアインスタンスをキャッシュにマッピングすることにより、キャッシュとやりとりする時にそのストアインスタンスを使うよう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との情報のやり取りに使用されるか確認してください。

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

ファイル:caching-27-12-default-store-mapping.png
マッピングが存在しない場合に使用されるストアに関する設定スクリーンショット

これは特定のマッピングが存在しない場合にキャッシュタイプに使用されるデフォルトストアの実際の設定です。

マッピングを設定するには最初にキャッシュ設定画面を表示してください。
「マッピングが存在しない場合に使用されるストア」テーブルを探してください。
テーブルの下に「マッピングを編集する」リンクがあります。そのリンクをクリックしてください。

関連するタイプのキャッシュが初期化された場合、あなたにはそれぞれのキャッシュタイプに使用できる1つのストアを選択できる画面が表示されます。これには明示的なマッピングはありません。

このインターフェースにおいて、タイプへのマッピングに適切なストアインスタンスのみがドロップダウンメニューに含まれることに留意してください。 すべてのインスタンスを表示する必要はありません。あなたに表示しないストアインスタンスがある場合、存在する「すべて」のキャッシュ定義は適切ではありません。
あなたはこのストアインスタンスをデフォルトにはできません。代わりにこのストアインスタンスを使用したいキャッシュに明確にマップする必要があります。

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

これは本当に微妙な場所であり、残念ながら、これに関してステップバイステップのガイドはありません。

どのようしてキャッシュを最良の状態に設定するかは問題となるサイトおよび利用可能なリソースに完全に依存します。

あなたが何を提供できるかは今後物事を考えてアイデアを生み出すためのヒントとなります。

このドキュメントを読んでキャッシュの設定に関して1つまたは2つを学べた場合、ここに追加することであなたの学びを共有してください。

  • キャッシングを計画してください。キャッシングは複雑なものです。あなたのサイトを理解してください。あなたのシステムを理解してください。そして、あなたのユーザがキャッシュをどのように使うのか十分に考えてください。
  • あなたのサイトの規模が小さい場合、顕著な効果は望めない可能性があります。あなたのサイトの規模が大きい場合、キャッシングを正しく設定することでパフォーマンスを十分に向上できます。
  • キャッシュバックエンドを判断する場合、メリットおよびデメリットを十分に考えてください。メリットおよびデメリットを考える場合、あなたのサイトのことを留意してください。あなたのサイトによりますが、1つのキャッシュバックエンドだけではサイト全体の要求を満たすことができず、自由に複数のバックエンドを持つことにより利益を享受できる場合もあります。
  • 通常、キャッシュバックエンドのインストールおよび使用のように簡単ではありません。キャッシングに関して設定および最適化に注意を払ってください。キャッシングを別の場所でテストした後、Moodleに伝える前にパフォーマンスに関して理解してください。あなたはキャッシュによりデータベースの負荷を軽減してページリクエスト処理を削減できます。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:

関連情報

「https://docs.moodle.org/2x/ja/index.php?title=キャッシング&oldid=19355」から取得
Powered by MediaWiki