16.6.5 memcached の FAQ

16.6.5.1. memcached は Windows 環境で実行できますか。

16.6.5.2. memcached に格納できるオブジェクトの最大サイズはどれくらいですか。それは構成可能ですか。

16.6.5.3. memcached はデータベースへの書き込みの多いアプリケーションよりデータベースの読み取りの多いアプリケーションでより効果的であるというのは本当ですか。

16.6.5.4. 永続的な接続を使用しないことのオーバーヘッドはありますか。永続的な接続が常に推奨される場合、そのデメリットは何ですか (たとえば、ロックの問題)。

16.6.5.5. memcached クライアントによって操作されている memcached サーバーのいずれかがクラッシュした場合はどうなりますか。

16.6.5.6. memcached サーバーの推奨されるハードウェア構成はどのようなものですか。

16.6.5.7. memcached は、テキストの読み取り/書き込みよりもビデオおよび音声に効果がありますか。

16.6.5.8. memcached は ASPX で動作しますか。

16.6.5.9. memcache の接続を確立するにはどのくらいコストがかかりますか。それらの接続はプールするべきですか。

16.6.5.10. memcached サーバーが停止した場合、データはどのように処理されますか。

16.6.5.11. MySQL データベースの自動インクリメントカラムは、複数の memcached インスタンスでどのように調整されますか。

16.6.5.12. 圧縮を使用できますか。

16.6.5.13. 異なるタイプの memcached を同じサーバーで別々のノードとして実装し、同じサーバーで決定性のあるものと決定性のないものを持つことはできますか。

16.6.5.14. パフォーマンスが向上することを確認するため、および memcached への構成変更の影響を判断するために、実装をテストするベストプラクティスはどのようなものですか。開始時の構成を単純にすることを推奨しますか。

16.6.5.1.	memcached は Windows 環境で実行できますか。
	いいえ。現在、memcached は Unix/Linux プラットフォームでのみ使用できます。使用可能な非公式の移植版については、http://www.codeplex.com/memcachedproviders を参照してください。
16.6.5.2.	memcached に格納できるオブジェクトの最大サイズはどれくらいですか。それは構成可能ですか。
	デフォルトの最大オブジェクトサイズは 1M バイトです。memcached 1.4.2 以降では、-I コマンド行オプションを使用してオブジェクトの最大サイズを変更できます。 これより前のバージョンの場合、このサイズを増やすには memcached を再コンパイルする必要があります。ソース内の slabs.c ファイルの POWER_BLOCK の値を変更できます。 memcached 1.4.2 以降では、-I コマンド行オプションを使用して、サポートされる最大のオブジェクトサイズを構成できます。たとえば、最大のオブジェクトサイズを 5M バイトに増やすには、次のように実行します。 $ memcached -I 5m オブジェクトが最大のオブジェクトサイズより大きい場合は、それを手動で分割する必要があります。memcached は非常に簡単であり、キーとデータを渡すと、それを RAM にキャッシュすることが試みられます。デフォルトの最大サイズを超えて格納しようとすると、速度を保つために値が切り捨てられます。
16.6.5.3.	memcached はデータベースへの書き込みの多いアプリケーションよりデータベースの読み取りの多いアプリケーションでより効果的であるというのは本当ですか。
	はい。memcached は、データベースへの書き込みに関与することはなく、データベースからすでに読み取ったデータを RAM にキャッシュする方法です。
16.6.5.4.	永続的な接続を使用しないことのオーバーヘッドはありますか。永続的な接続が常に推奨される場合、そのデメリットは何ですか (たとえば、ロックの問題)。
	memcached と通信するときに永続的な接続を使用しない場合、毎回接続を開くときに待機時間が少し長くなります。その影響は、MySQL に永続的ではない接続を使用する場合と同等です。 一般に、memcached 内でロックが使用されることは非常に少ないため、永続的な接続でロックまたはその他の問題が発生する可能性はごくわずかです。問題がある場合は、要求がタイムアウトして結果が返されないため、アプリケーションが MySQL からふたたびロードする必要があります。
16.6.5.5.	memcached クライアントによって操作されている memcached サーバーのいずれかがクラッシュした場合はどうなりますか。
	これは自動的に処理されません。クライアントがサーバーから応答を取得できない場合、MySQL データベースからデータをロードするためのフォールバックメカニズムをコーディングしてください。 すべてのクライアント API は、memcached インスタンスを実行中に追加および削除する機能を提供しています。アプリケーションで memcached サーバーが応答しなくなったことが認識された場合は、そのサーバーをサーバーのリストから削除すると、キーがリスト内の別の memcached サーバーに自動的に再配分されます。すべてのサーバーでキャッシュの内容を維持することが重要である場合は、一貫性のあるハッシュアルゴリズムをサポートする API を使用してください。詳細は、セクション16.6.2.4「memcached のハッシュ化/分布タイプ」を参照してください。
16.6.5.6.	memcached サーバーの推奨されるハードウェア構成はどのようなものですか。
	memcached の処理オーバーヘッドはごくわずかです。必要なのは余剰の物理 RAM 容量のみです。memcached サーバーには専用のマシンは必要ありません。余剰の RAM 容量がある Web サーバー、アプリケーションサーバー、またはデータベースサーバーがある場合は、それらを memcached に使用します。 専用の memcached サーバーを構築および配備する場合は、比較的性能の低い CPU、大量の RAM、および 1 つ以上のギガビット Ethernet インタフェースを使用します。
16.6.5.7.	memcached は、テキストの読み取り/書き込みよりもビデオおよび音声に効果がありますか。
	memcached はすべての種類のデータに対して同様に動作します。memcached を実行した場合、格納される値はデータのストリームです。ただし、memcached に格納できるオブジェクトの最大サイズは 1M バイトですが、memcached 1.4.2 以降では -I オプションを使用することによって、またはバージョン 1.4.2 より前はソースを変更することによって、それより大きく構成できます。音声およびビデオのコンテンツに memcached を使用することを計画している場合は、最大のオブジェクトサイズを増やすことがほとんどです。また、memcached は読み取りのために情報をキャッシュするソリューションです。キャッシュの情報を更新するときを除いて、書き込みに使用しないでください。
16.6.5.8.	memcached は ASPX で動作しますか。
	多数の言語および環境のための移植版およびインタフェースがあります。ASPX はベースとなる言語 (C#、VisualBasic など) に依存しています。ASP.NET を使用している場合は、C# の memcached ライブラリがあります。詳細は、https://sourceforge.net/projects/memcacheddotnet/ を参照してください。
16.6.5.9.	memcache の接続を確立するにはどのくらいコストがかかりますか。それらの接続はプールするべきですか。
	リクエストの送信および結果の取得を開始する前に、セキュリティー、認証、またはその他のハンドシェイクは行われないため、接続のオープンには比較的コストはかかりません。ほとんどの API は、待機時間を減らすために、memcached インスタンスへの永続的な接続をサポートしています。接続プールは、使用している API によって異なりますが、TCP/IP を介して直接通信している場合は、接続プールのパフォーマンスが若干よくなります。
16.6.5.10.	memcached サーバーが停止した場合、データはどのように処理されますか。
	その動作はアプリケーションによってまったく異なります。ほとんどのアプリケーションは、データベースからデータをロードすることにフォールバックします (memcached の情報を更新するときのように)。複数の memcached サーバーを使用している場合は、停止したサーバーをリストから削除して、パフォーマンスに影響しないようにできます。そうしないと、クライアントはロードしようとしているキーと対応している memcached サーバーと通信することを試みます。
16.6.5.11.	MySQL データベースの自動インクリメントカラムは、複数の memcached インスタンスでどのように調整されますか。
	調整されません。MySQL と memcached に関連はありません (アプリケーションにそのような関連を作成した場合 (または、memcached およびデータベース定義に MySQL UDF を使用している場合) を除きます)。 memcached の複数インスタンスに自動インクリメントキーに基づいて情報を格納している場合、情報はいずれかの memcached インスタンスに格納されるのみです。クライアントは、キー値を使用して、情報が格納されている memcached インスタンスを判別します。同じ情報は、キャッシュメモリーが無駄になるため、すべてのインスタンスに格納されません。
16.6.5.12.	圧縮を使用できますか。
	はい。ほとんどのクライアント API は何らかの圧縮をサポートしており、格納中に値が圧縮に適しているかどうかを判断するしきい値を指定できるものもあります。
16.6.5.13.	異なるタイプの memcached を同じサーバーで別々のノードとして実装し、同じサーバーで決定性のあるものと決定性のないものを持つことはできますか。
	はい。単一のサーバー上で memcached の複数のインスタンスを実行し、使用するサーバーのリストをクライアントの構成で選択できます。
16.6.5.14.	パフォーマンスが向上することを確認するため、および memcached への構成変更の影響を判断するために、実装をテストするベストプラクティスはどのようなものですか。開始時の構成を単純にすることを推奨しますか。
	パフォーマンスをテストする最適な方法は、memcached インスタンスを起動する方法です。最初に、データが使用または表示される直前にデータを memcached に格納するようにアプリケーションを変更します。API によってデータが直列化されるため、コードを 1 行変更すればよいだけです。そして、通常は MySQL から情報をロードするプロセスの開始を、memcached にデータをリクエストするコードに変更します。memcached からデータをロードできない場合は、デフォルトで MySQL プロセスからロードされます。 変更する必要があるのはおそらく数行のコードのみです。利点を最大に活用するには、memcached を MySQL テーブルの個別の行の単純なキャッシュとして使用するのではなく、オブジェクト全体 (たとえば、Web ページ、ブログの投稿、ディスカッションスレッドなどのすべてのコンポーネント) をキャッシュしてください。 memcached では、開始時の構成を単純にすること、または長期間にわたってそれを維持することは簡単です。基本的な構造を作成して実行したら、多くの場合、使用中に変更することは、アプリケーションによって使用されるサーバーのリストにサーバーを追加することのみです。memcached サーバーを管理する必要はなく、複雑な構成はありません。リストにサーバーを追加したら、クライアント API および memcached サーバーに判断を任せます。