ネットワークキャッシュのMemCacheとMongoDbの比較

MemCacheではなくMongoDbをネットワークキャッシュの手段として使用し、そのパフォーマンスを比較するという、並外れたアイデアが生まれました。 しかし、これら2つの「キャッシングメカニズム」のパフォーマンスを表して比較するために、アプリの作業を高速化する他の手段（ APC 、 RamFS 、 TmpFS 、 XCache ）も使用しました。

この記事では、これらのメカニズムをデータとグラフの説明と推論と比較するデータとグラフを紹介します。



大規模なインターネットリソースは、遅かれ早かれサーバー負荷の問題に直面します。 サーバーが1台しかない場合や、WebサーバーとDBサーバーが多数ある場合は、すべてうまくいきます。 一般に、フロントエンド（フロントエンド）が1つしかない場合、すべてが比較的良好です。 しかし、ここでは、サーバーの「動物園」を増やすときに問題が発生します！ サーバー間の接続の階層がより複雑になるだけでなく、一元化されたデータストレージなどの問題もあります。これは、データベース、静的ファイル、そしてもちろんキャッシュファイル自体に適用されます。



職場では、1台のサーバーをはるかに超えたかなり大きなインターネットリソースを開発しています。 これまでの利点は、WebサーバーとDBサーバーに限定されています。 しかし、当局は現在、新しい大規模なプロジェクトを開始しました。このプロジェクトでは、そのクレイジーな構造がデザインと思考のレベルですでに見えています。 プログラマーの小さなグループは、新しく興味深い仕事に直面しています。プロジェクトの構造と階層を考え直すことです。私たちの誰もこれまでに経験したことのない規模です。 しかし、これはこのプロジェクトに関するものではなく、その開発から生じる問題、つまり、主なものはキャッシュの集中ストレージです。



この記事は、この問題に対する包括的な解決策を示しているわけではありませんが、ツールやキャッシュスキームの比較や選択で得た経験を共有できます。



記事の主要部分、つまり報告会に進みます。

キャッシングパフォーマンスを比較するために、 APC 、 MemCache 、 RamFS 、 TmpFS 、 XCache 、および（特別な選択）、かなり高速なDBMS MongoDBのキャッシングツールが選択されました。



これらすべてのプログラムと拡張機能をどのようにインストールしたか、どのような困難に直面したかから始める必要があると思います。

すべての実験は、2GbのメモリとインストールされたPHP [5.3.6]を備えたCentOSシステムで実行されました。公平を期すために、単一のパッケージを構成せずに、すべてを「箱から取り出し」ました。



APC [3.1.9]のインストール：

すべてがシンプルで簡単です。 peclを介してパッケージをインストールすると、APCが動作します。



Memcacheインストール[2.2.6] ：

また、非常に簡単です。 また、peclを介してパッケージをインストールしてから、memcacheプログラム自体を個別にインストールします。 これは拡張機能ではなく、個別にインストールする必要があるサードパーティのプログラムですが、難しくはありません。 インストール後、すべてが素晴らしく機能しました。



RamFSをインストールします。

インストールよりもさらに作成されます。 すべてが非常に簡単です： mount -t ramfs -o size=1024m ramfs /tmp/ramfs



、ここでは1Gbのメモリを割り当て、ファイルシステムとして/tmp/ramfs



マウントします。



TmpFSをインストールします。

また、過去の場合と同様に、これはインストールではなく作成です。 これは、 mount -t tmpfs -o size=1024m tmpfs /tmp/tmpfs



コマンドmount -t tmpfs -o size=1024m tmpfs /tmp/tmpfs



で作成されます。これは、1Gbのメモリも割り当て、 /tmp/tmpfs



ファイルシステムとしてマウントすることを示しています。



注：

RamFSとTmpFSの主な違いは次のとおりです。RamFSに割り当てられた制限に達すると、システムは使用されたボリュームの制限について通知せず、記録した新しいデータは単に消えることを除いて、両方の方法はほぼ同じように機能しますTmpFS（割り当てられた制限に達したとき）はスペース不足に関するメッセージを表示しますが、古いデータはスワップに移動されます。つまり、ディスク操作が実行されますが、実際には私たちには適していません。 RamFSとTmpFSは両方ともゼロにリセットされ、システムの再起動時に消えます。したがって、システムの再起動後でも使用したい場合は、起動時にこれらのパーティションを作成するためのスクリプトを配置する必要があります。

XCache [1.3.1]のインストール：

そして、ここから私たちが直面している興味深いことが始まります。 このパッケージのインストールは、PHP 5.2もシステムにインストールされている（そして現在それがシステムのメインの1つである）ため、非常に慎重であることが判明しました。XCacheには多数の依存関係リストがあり、このパッケージのインストールにはスリップする必要があるため問題がありました彼には図書館が必要です。 しかし、この場合でも、この拡張機能の問題は終わりませんでした。インストール後（および正常と思われる）、この拡張機能の正しい動作を確認するテストを含むスクリプトの起動中に、変数をメモリに書き込もうとすると新しい問題が発生したためですエラーが発生しました：



Warning: xcache_set(): xcache.var_size is either 0 or too small to enable var data caching in /usr/local/php5.3/xcache.php on line 6







彼女に続いて次のようになりました：



Warning: xcache_get(): xcache.var_size is either 0 or too small to enable var data caching in /usr/local/php5.3/xcache.php on line 10







真っ直ぐな手、キーボード、タンバリンでこのエラーと2日間戦いましたが、結果はゼロでした。 * .soが誤ってアセンブルされたという憶測がありましたが、収集した* .soをインターネットからダウンロードした同じバージョンに置き換えても何も起こりませんでした。 Googleおじさんが行動を起こし、まったく同じStackOverflowの問題が見つかりました。 しかし、彼らはこの問題の解決策を見つけられなかったため、XCacheなしでさらにテストを行うことを余儀なくされました。 以前のテストでは、APCとXCacheの違いはほとんど重要ではないことが示されたため、それほど失望することはありませんでしたが、XCacheにはさらに多くの問題があります。



MongoDB [1.8.1]をインストールします。

Mongoのインストールは非常に簡単で、そのプロセスについては説明しませんが、必要な構成で起動を提供します。

/usr/local/mongodb/bin/mongod --dbpath /usr/local/mongodb/data --profile=0 --maxConns=1500 --fork --logpath /dev/null --noauth --diaglog=1 --syncdelay=0





関心のある主なパラメーターは、最後の「 --syncdelay=0



」です。これは、メモリ内のデータとHDD上のデータの同期時間を示します。 指定された値0は、HDDとのMongo同期を明示的に禁止することを意味します。この機能はDBMSの作成者によって記述されていますが、停電やMongoデーモンに影響を与える可能性のある他のシステム障害のため、すべてのデータが失われます。 私たちはこのリスクに非常に満足しています。 このDBMSをキャッシュメカニズムとして使用してみます。



すべてがインストールされ、「構成」されているようです。テスト自体に直接進んでください。



正直に言うと、4つのデータボリューム（4Kb、72Kb、144Kb、2.12Mb）でテストを実施します。



グラフで得られたデータを考慮してください。



4Kb：



最初のチャート（4Kbデータを記録するためのタイムライン）でわかるように、MemCacheは最悪の結果を示し、RamFsとTmpFs、MongoとAPCがそれに続きました。





2番目のグラフ（4Kbデータを読み取るためのタイムライン）では、Mongoが後方のデータをはっきりとかすめていますが、MemCacheはRamFとTmpFにほぼ匹敵しますが、このグラフでは、両者の差異はほとんど見えません。



72Kb：



3番目のチャート（72Kbデータを記録するためのタイムライン）から、MemCacheは不適切に動作し、Mongoは非常に予測可能です。 APC、RamF、およびTmpFがほぼ一致したことは非常に驚くべきことです。





そして、4番目のチャート（72Kbデータを読み取るためのタイムライン）に表示される読み取り値は次のとおりです。



144Kb：



5番目のグラフ（144Kbデータ記録タイムライン）から開始すると、ほぼすべてのシステムで既に奇妙な動作が見られます-MemCacheは非常に不安定に動作し、繰り返しの回数が少ないと、時間が大きいものよりもさらに長くなり、さらに驚くべきことに、 500回の繰り返しMongoがAPCを追い越し始めました！ RamFおよびTmpFは、驚くほど高い速度を維持します。





6番目のグラフ（144Kbデータを読み取るためのタイムライン）では、Mongoが全員に負けており、APCが最速です。



2.12Mb：



7番目のグラフ（2.12Mbデータを記録するためのタイムライン）では、Mongoは非常に安定していることが判明しましたが、最後の繰り返しで500回は不安定でしたが、彼はサドルにとどまりました。 もちろん、わいせつなリーダーはAPCですが、以下で説明するMemCache、TmpF、およびRamFで興味深いことが起こっています。





最後のグラフ（2.12Mbデータのタイムラインの読み取り）も非常に素晴らしい画像です。TmpFsが最も遅く、RamFsが最も速く出てきました。 もう1つの驚くべきことは、MongoがAPCよりも優れていることです！



ファイルが2.12Mbで500回キャッシュされた最後の2つのグラフの最後の繰り返しを見ると、500（繰り返しの数）* 2.12（1つのファイルのサイズ）= 1`060Mbというかなり興味深いことがわかります。 RamFSおよびTmpFSでは、最大ボリュームを超えました。 したがって、数字は非常に興味深く、予測不可能です。

実際、すべてが予想通りに判明しました。上限に達すると（そして1024Mbに達すると）、RamFSは単にデータの書き込みを停止し、書き込みコマンドを無視します。 このデータを読み取るとき、読み取りは物理的に行われませんが、空の文字列を返すだけです（PHPで処理する場合、文字列は空ではなく、nullとして解釈されます）。一方、TmpFSはまったく逆に動作します-すべてのデータを書き込み、事前に割り当てます古いデータをスワップに移動して配置します。 これは、そのようなボリュームと同様の反復回数で、RamFSがレコードを処理するのに非常に短い時間を要し、存在しないデータを読み取る時間をさらに短縮するという事実を説明しますが、TmpFSは逆に、ディスク操作を実行する必要があるためにこの時間を大幅に増やします

上で示したように、すべての資金は「箱から出して」すぐに取り出され、これらのツールは構成されていません。したがって、memcacheの時間は0です。 サイズが2.12MBの1つのレコードの記録されたボリュームは、memcacheに保存されている1つのレコードの最大量を単に超えています。 memcacheが2.12Mbを超えるデータを保存できるようにするには、memcache自体を再構築する必要がありますが、それ以外のすべてを適宜構成する必要がありますが、同じ方法で異なる製品を構成することはほとんど不可能なので、このニュアンスをそのままにしておきます今のままです。 おそらくこれは真実ではありませんが、私たちはこれらのすべての手段が同等の条件で動作することにもっと興味がありました。



このすべてのデータを見ると、各開発者は自分自身の結論と、何をどのように使用するかについての結論を引き出すことができます。 私たちは結論を出しました。

ネットワークを介してキャッシュできるツールのデータに関心があるため、MemCacheとMongoについて説明します。 もちろん、多くの場合、グラフが示すように、MemCacheは読み取り時にMongoをバイパスします。これは、MongoがMemCacheをバイパスするレコードよりも重要です。 ただし、MongoDbが提供するすべての機能を考慮すると、当然のことながら、すべての機能と操作のしやすさを備えた本格的なDBMSであるため、Mongoが示す速度の欠点は、複雑なサンプルを作成する機能によって簡単にカバーできます。 1つのリクエストで複数のエントリ（キャッシュエントリ）を取得します。 MemCacheを介したMongoDbのもう1つのプラス：適切でよく考えられたアプリアーキテクチャを使用すると、1つのリクエストでキャッシュされたページ要素を受け取ることができます。



また、システムをマルチレベルキャッシュ（一次キャッシュ（ネットワークキャッシュ）MemCacheまたはMongo、および二次キャッシュAPCまたはXCache（ただし、比較が必要です））があると考えることもできます。



近い将来、MemCacheとMongoのより詳細な分析と比較が計画されています-費やされた時間だけでなく、プロセッサとサーバー全体の負荷を測定して、使用されたメモリも比較されます。



最後に、テストが繰り返し実行され、表に示されているデータがテストの10〜20回の繰り返しの平均であることを示したいと思います。

ボリュームが大きいため、表形式のテストデータは提供しません。