Tarantool：ストレステスト

記事「 Tarantool：Good、Bad、Evil 」では、PHPの有効な例を使用した簡単な投票サービスについて説明しています。 このNoSQLデータベースをプログラムで簡単に接続して使用できることがわかりました。 しかし、1つの重要な質問が無視されました-これはなぜですか？ NoSQLを使用すると、通常のデータベースと比較してどのようなパフォーマンスが向上しますか？
行こう！
この質問に答えるために、サーバーの1つをテストします。 1 GBのメモリを搭載した仮想マシンと、次のパラメーターを備えたプロセッサコアを実行します。

processor: Intel(R) Xeon(R) CPU E5-26xx (Sandy Bridge) cpu MHz: 1999.999 cache size: 4096 KB bogomips: 3999.99 

SSDのディスクサブシステムは悪くありません：

 hdparm -t /dev/sda1 /dev/sda1: Timing buffered disk reads: 484 MB in 3.00 seconds = 161.13 MB/sec 

ホスティング事業者は、仮想サーバーで100 Mbpsの帯域が利用可能であると主張しています。 そして、私たちのテストでは高いネットワーク速度が示されましたが、この制限は当然のものと考えます。 Nginxバージョン1.6.2 、 php / php- fpmバージョン5.6.30、Tarantoolバージョン1.7.3

テストには、 wrkユーティリティを使用します。 さまざまなwrkパラメーターといくつかのnginxチューニングを使用したいくつかのテストの後、後者はこの構成を取得しました。

 worker_processes 1; events { worker_connections 1024; multi_accept on; use epoll; } http { # Timeouts keepalive_timeout 60; # TCP options tcp_nodelay on; tcp_nopush on; # Compression gzip on; gzip_comp_level 5; … } 

wrkユーティリティは、最終的に50の同時リクエストで実行されました。 リクエストの数を減らすと、サーバーのパフォーマンスを最大化できません。 100以上のリクエストを追加すると、1秒あたりのリクエストのパフォーマンスはわずかに向上しますが、遅延は急速に増大し始めました。 最終的に、同時リクエスト数の増加により損失が発生しました。 ただし、このスコアにはすばらしい説明があります。



Konstantin Osipovによる記事とキューを処理するためのテクニックから

タランチュラのテスト結果

測定されたサーバーとトラフィックジェネレーター間のネットワークpingは32ミリ秒でした。 念のため、テストマシンは、結果の客観性のために試用テスト後に再起動されました。 以下のデータが取得されました。

 wrk -c50 -d60s -t4 http://ugly.begetan.me/good Running 1m test @ http://ugly.begetan.me/good 4 threads and 50 connections Thread Stats Avg Stdev Max +/- Stdev Latency 54.48ms 10.15ms 441.17ms 95.62% Req/Sec 220.76 19.43 270.00 74.65% 52760 requests in 1.00m, 320.86MB read Requests/sec: 878.72 Transfer/sec: 5.34MB 

54ミリ秒の応答時間で、1秒あたり900件弱のリクエストを処理することができました。 それはたくさんですか、それとも少しですか？ まず、サービスのスクリプトでページにアクセスすると何が起こるかを覚えておいてください。

1. スクリプトは新しいクライアントの魅力を確認し、存在しないCookieを読み取ろうとします
2. 固有のuuidがタランチュラで生成されます
3. Tarantulaでは、upsert writeコマンドが実行され、クライアントのuuid、時間、IP、およびユーザーエージェントが記録されます。
4. このスクリプトはタランチュラチームを呼び出します。タランチュラチームは、評価インデックスを使用して、16,000件のレコードのうち上位9件を選択します

そして、これらすべてを合わせると、可能な限り低いVPSで約1ミリ秒かかります。これほど安いものはありません！ テスト中、セッションテーブルには100万を超えるエントリがありましたが、これはサーバーのパフォーマンスにはまったく影響しません。 これは悪くないように思えますか？

追加の情報は、 topユーティリティの出力から取得できます。 すでに述べたように、テストを開始する前にサーバーが再起動されました。 スクリーンショットは、再起動の瞬間から2番目のベンチマークの起動時に取得されました。


この図は、タスクのプロセッサー時間の分布を示しています。 約4分の1のリソースがタランチュラによって直接消費されています。 リソースの主な消費者はphp-fpmハンドラーであることが判明しました。 3位はnginxでした。 並列wrk要求の数を増やすと、nginxが消費するプロセッサー時間が増加しました。 このため、php-fpmに十分なリソースがなく、ログでエラー499および502が発生しました。

この時点で、アプリケーションを書き直し、Tarantulaを通常のSQLデータベース（ MySQLまたはPostgreSQL ）に置き換えて、結果を比較するのが正しいでしょう。 しかし、著者は役に立たない仕事のファンではないので、彼は別のオプションを思いつきました。 Tarantulaなしでphp-fpmバンドルをテストし、パフォーマンスがどのように変化するかを確認します。

タランチュラを使用しないテスト結果

まず、wrk（オプション-c50）でテストするために正確に50の同時接続を取得した理由を見てみましょう。 1つのテストフローを開始すると、ページの読み込みが順番に何度も繰り返されます。 ネットワーク信号の伝播遅延とゼロ以外のリクエスト処理時間が存在するため、1つのストリームからの負荷は非常に弱いです。 したがって、並列クエリの数を増やし始め、テスト結果とサーバー負荷で何が起こるかを調べています。 同時要求の数が増えると、nginxプロセスの％CPUがほぼ均等に増加します。 負荷が大きくなりすぎると、サーバーのプロセッサリソースが不足しなくなり、一部のテスト要求でエラーが発生します。 それらはwrkのタイムアウトで終了するか、Webサーバーがバックエンドのアクセス不能に関するエラー502を返します（この場合はphp-fpm）。

これらすべての中で最も重要なことは、テストパラメータがホスティング構成とテストサーバー専用に選択されていることです。 たとえば、ローカルネットワーク上で別のバンドルをテストするには、他のパラメーターを選択する必要があります。

ここでチャートを見てみましょう。それから、いくつかの興味深い点を示します。


そのため、プログラムでタランチュラに対処する代わりに、このようなスタブを農民的な方法で貼り付けました。


また、一般的にTarantulaへのすべての参照をオフにして削除し、スクリプトを実行します。 グラフ（nginx + phpシリーズ）からわかるように、Tarantulaが50スレッドで無効にされたとき、879リクエストではなく1150リクエストを受け取りました。 速度の増加はわずか30％でした。 かっこいい いや！ 実際、このテストは何の意味もありません。 なぜなら、最初にサイトの負荷を選択して、100％負荷になるようにしたためです。 しかし、今では1つのリソースを大量に消費するプロセス（合計時間の約30％）を無効にしているため、サイトは完全に読み込まれていません。 チェック？

サーバーの負荷がさらに増加すると、青色のグラフが大きく成長することがわかります。 また、Tarantulaを使用しない150のテストスレッドを使用すると、タランチュラの場合は1,000件ではなく、毎秒約3000件のリクエストを受信しました。 今ではすべてが正しい。

ところで、TarantulaはなぜテストでCPUの30％しか使用しませんでしたが、それをオフにすると、サーバーのパフォーマンスは3倍になりましたか？ 答えは簡単です。タランチュラをオフにすると、php-fpmワーカーの負荷も減少しました。 負荷の増加は、nginxプロセスによるCPU消費の増加によるものです。 テストエラーが発生し始めるまでスレッド数を増やして、この負荷を増やしました。

次に、1つの興味深い点を見てみましょう。 Tarantool + Connectグラフとは何ですか？ いつものように、興味深い点は偶然見つけられます。 最初にTarantulaプロシージャの呼び出しをすべてオフにしてテストを実行したときに状況が発生しましたが、TarantulaプロセスにはまともなCPUが残っていることがわかりました。 接続のセットアップ手順、この部分についてコメントするのを忘れていたことが判明しました：

 # Init database $tarantool = new Tarantool('localhost', 3301, 'good', 'bad'); try { $tarantool->ping(); } catch (Exception $e) { echo "Exception: ", $e->getMessage(), "\n"; } 

Tarantool + Connectグラフは、計算操作なしで、接続の初期化のみでシステムパフォーマンスを示します。 デモアプリケーションでは、Tarantulaプロセスの使用のほとんどは、計算タスク自体ではなく、接続確立手順によって提供されることが判明しました。 CPUシェアに関して、正確な調整は次のとおりです。Tarantool+ Connectテストの場合は20％、データベースとしての本格的な作業の場合は28％です。

どんな結論がありますか？ Tarantulaへの接続プロセスがリソースを大量に消費する操作であるか、PHPドライバーが最適に動作しない可能性があります。 重要なことは、たとえばC、Java、またはGoで作成されたデーモンから永続的な接続を確立すると、同じ操作でCPUの使用量が4倍少なくなることです。 これは、プログラムを作成するときに考慮する必要があります。

WALまたはWALではない？

最後に、最後のテストは非常に単純ですが、開発者にとって非常に興味深いものです。 既に知っているように、TarantulaはSnapshootメカニズムとWrite Ahead Logのおかげでデータの安全性を宣言しています。 1つ目は通常のデータベースキャストを作成して書き込み、2つ目はすべての変更を特別な変更ログに書き込みます。 突然のシャットダウンまたはサーバーのクラッシュが発生した場合、変更は保存され、システムの再起動時に復元できます。

WALログをオフにして負荷をテストしました。 50ストリームでは、rpsの数は879から963に増加しました。追加のログファイルのディスクへの書き込みを無効にすると、100％ロードされたシステムが高速化されることは明らかです。 ただし、速度の増加が測定誤差に近いことは明らかであり、代償を払う価値はまったくありません。 貴重なデータの安全性を確実に確認することをお勧めします。

あとがきの代わりに

以前は、Web開発では、「なぜ、データベースが遅くなるにせよ、高速プログラミング言語を使用してWebフロントエンドを作成する」というトピックに関する議論が一般的な場所でした。 現在、ハードウェア、仮想化、NoSQLソリューションが成長するにつれて、データベースはアプリケーションのボトルネックではなくなります。

私個人にとって、1つの重要な質問は不明のままです。 タランチュラは、開発者が証明しようとしているのと同じくらい信頼できるリポジトリですか？ 「じゃあ、そうじゃないの？」とある歌が言っているように。 「Break the Tarantula」と呼ばれるデータ損失テストを実施したいと思いますが、実際に厳しい条件をシミュレートするには、懐疑論者、嫌いな人、競合他社、Mail.ruの嫌いな人の助けとアドバイスが必要です。 なぜなら、 プラトンは私の友人ですが、真実はもっと貴重だからです！ 」

デモサイトugly.begetan.meに投票することを忘れないでください！ そして、あなたはトップセクションから同じアライグマを毎回レイアウトしなければなりません。