ランダムサーバーのパフォーマンスをすばやく測定する方法

Web開発の世界では、多くの場合、Webアプリケーション用のサーバーを選択するか、既存のサーバーのパフォーマンスをチェックするというタスクが発生します。 おそらく、予想される負荷に耐えられるように、新しいサーバーを購入する必要があります。 顧客が既存のサーバーを展開用に送信する場合があります。 いずれにせよ、アプリケーションをデプロイして起動した後、パフォーマンスが低下する場合は、チームに尋ねます。

主な問題は、特別な（読み取り、複雑な）ツールを使用せずに、そしてもちろん、リリース前に、サーバーのパフォーマンスを迅速に評価する必要があることです。 サーバーから特定のメトリックを削除し、それらにアプリケーションの既知のインジケーターを掛けて、このサーバーでのアプリケーションのパフォーマンスの推定値を取得できる必要があります。

人生では、すべての開発者がこのタスクを達成できるわけではなく、残りのすべての開発者がそれを達成したいとは限りません。

この記事では、サーバーのパフォーマンスを評価するために使用する手法とツールについて説明します。

典型的な状況

1番

開発チームはリリース中であり、製品の最初のバージョンをリリースする準備を間もなくしています。 次のステップは、戦闘サーバーにアプリケーションをデプロイすることです。これは、プロジェクトの条件に従って、購入して構成する必要があります。 一般的な集会で、プロジェクトマネージャーは、この「単純な」質問を解決する責任者を見つけることを提案します。 必要な金額を次の反復の予算に入れます。」 原則として、このタスクを希望する人はいません:)。 さらに、直接の委任-「Vasya、このタスクを実行してください！」-も機能しません。Vasyaは、すぐにそれに関連して昨日完了しなければならない少なくとも12個の緊急/重要タスクを即座に見つけてリストします（そして、一般的に、 -管理者ではありません "）。 自己保存の一般的な感覚に従って、チームはプロジェクトマネージャーにそのような専門家をどこに探すべきかを正確に調和させて伝えます（隣のユニットよりも近くない）。

番号2

プロジェクトの条件に従って、サーバーは顧客から提供されます。 プロジェクトの開始時には素晴らしい状態に見えますが、リリースに来たときはそうではありません。 クライアントの質問「サーバーは強力ですか？」に対する変更のない答えは次のとおりです。 展開後、プロジェクトマネージャーは、Webアプリケーションの応答のタイミングを悲しげに見ます。 「誰が責任を負うべきか」、「何をすべきか」という不快な考えがあります。 サーバー構成を自分で選択する必要があるという理解がありますが、一方で、隣接ユニットの専門家は見つかりませんでした。 実際、この強力なサーバーは安価なVPSであり、パラメーターは適切に見えますが、ホストリソースを仲間の軍隊と共有していることがわかりました。 クライアントは、5年前にサーバーの代金を支払いました:)、何も変更しません（言う前に）。

番号3

上級レベル-クライアントにはサーバーと管理者がいます。 サーバーのパラメーターは満足のいくものではありませんが、アプリケーションの展開後、ひどいブレーキ、遅延、遅延が発生します。 開発サーバーのパラメーターは3倍弱いですが、アプリケーションの実行速度は8倍高速です。 管理者が独自の意見を持っているため、サーバーの交換や新しいサーバーの購入に関する提案は受け入れられません。「あなたの」アプリケーションの速度が低下します。 クライアントは誰を信じるべきかを知りません。 彼はまた、新しい費用を伴うアイデアを好まないため、管理者の議論は重要です。 プロジェクトマネージャーは、「アプリケーションが遅くなる理由」とチームの明確な説明と、サーバーの「罪悪感」の数を示す証拠を必要とします。 いつものように、チームには十分な時間があるため、誰もが喜んでタスクを引き受け、隣の部署の専門家にビールを飲んで「どこを掘るか」というヒントをもらいます。

直面する状況と解決する必要があるタスクを要約します。

-アプリケーションと負荷のためのサーバーの選択
-既存のサーバーの機能の評価
-「なぜそんなに遅いの？」という質問に答えられるようになります。

測定ツールの要件

サーバーのパフォーマンスを測定する最も正確な方法は、同時に最も明白です。つまり、サーバーにアプリケーションをインストールし、実際の負荷をアクティブにする必要があります。 この方法では正確な結果が得られますが、多くの理由により役に立たない:)

• 運用を開始する前に、サーバーの評価を事前に知りたいです。
• 測定方法は高速で安価でなければなりません。
• 測定ツールは使いやすく、サーバーにインストールできる必要があります。
• 測定結果は簡単に解釈および比較する必要があります。

測定対象

サーバーが購入され、オペレーティングシステムがインストールされ、sshdが実行されています。 コンソールを開き、サーバーに入ります。 黒いコンソール、緑色の文字、点滅するコースが「次は何？」と静かに尋ねます。 私たちが何を測定するのか、そして生産性は何から作られるのかを考える時です。

ここまでの質問は単純でした。「ベンチマークを開始すると、すべてが明確になります。」 さて、コンソール上で点滅するカーソルを見ると、思考は停止し、必要なコマンドを与えることができません。

Webアプリケーションのパフォーマンスをより大きく決定するもの：

• CPU + RAMの速度
• ディスクサブシステムの速度
• 言語ランタイムのパフォーマンス（この場合はPHP）
• データベースのセットアップ（MySQLまたはPostgreSQLがあります）
• そして、もちろん、アプリケーション自体から（使用するリソースから）

作業の速度を個別に測定できる4つのツールが必要です。

• サーバーコンポーネントの場合：CPU + RAMおよびディスクサブシステム
• ソフトウェアコンポーネントの場合：MySQLおよびPHP

測定結果が手元にあれば、サーバー全体のパフォーマンスについて包括的に話すことができ、Webアプリケーションの動作を予測することもできます。

測定ツール

シスベンチ

github.com/akopytov/sysbench

著者が説明したよりもツールを説明することは不可能なので、引用します。

SysBenchは、集中的な負荷の下でデータベースを実行するシステムにとって重要なOSパラメーターを評価するための、モジュール式のクロスプラットフォームおよびマルチスレッドのベンチマークツールです。
このベンチマークスイートのアイデアは、複雑なデータベースベンチマークを設定したり、データベースをまったくインストールしなくても、システムパフォーマンスに関する印象をすばやく得ることです。

これが必要なものです！ Sysbnechを使用すると、複雑なベンチマークや特別なツールをインストールすることなく、システムパフォーマンスをすばやく把握できます。

sysbenchのインストールは簡単です：
apt-get install sysbench


コンパイルできます：
$ ./autogen.sh

$ ./configure

$ make


CPUパフォーマンスを確認する

これを行うために、2万個の素数の計算を開始します。
$ sysbench --test=cpu --cpu-max-prime=20000 run


デフォルトでは、計算は単一のスレッドで実行されます。 並列計算を実行する場合は、キー--num-threads = Nを使用します。

試験結果：

  CPU: Test execution summary: total time: 17.3915s total number of events: 10000 total time taken by event execution: 17.3875 per-request statistics: min: 1.66ms avg: 1.74ms max: 4.00ms approx. 95 percentile: 2.03ms 

このテストで最も興味深いのは、合計時間の値です。 このテストを複数のサーバーで実行することにより、測定値を比較できます。

この記事を書いている時点で指先にあったサーバーでこのテストを実行する例を示します。



注：

• G2はA3の約3倍高速です
• 250ルーブル/月のレグラのシンプルなVPSはG2に匹敵します:)
• Xeon X3440ベースの仮想マシンはNUC i5と同じように機能しました
• 4台のサーバーで驚くほど均一な結果
• 素数は、プロセッサ全体のパフォーマンスを反映しない同じCPUユニットで計算される可能性があります。

ディスクサブシステムのテスト

ディスクサブシステムの確認は、次の3つの手順で実行されます。

• テストファイルのセットを準備（生成）します
• テストを実行し、指標を取得する
• ごみを出す

テストファイルの準備：
$ sysbench --test=fileio --file-total-size=70G prepare


チームは、合計サイズが70ギガバイトのファイルセットを作成します。 オペレーティングシステムのキャッシュがテスト結果に影響しないように、サイズはRAMの量を大幅に超える必要があります。

テスト実行：
$ sysbench --test=fileio --file-total-size=70G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run


テストはランダムな読み取りモード（rndw）で300秒間実行され、その後、結果が表示されます。 繰り返しますが、デフォルトでは、テストは単一のスレッドで実行されます（スレッド数：1）。

一時ファイルのクリーンアップ：
$ sysbench --test=fileio cleanup


テスト結果の例：

  FileIO: Operations performed: 249517 Read, 166344 Write, 532224 Other = 948085 Read 3.8073Gb Written 2.5382Gb Total transferred 6.3455Gb (21.659Mb/sec) 1386.18 Requests/sec executed Test execution summary: total time: 300.0045s total number of events: 415861 total time taken by event execution: 178.9646 per-request statistics: min: 0.00ms avg: 0.43ms max: 205.67ms approx. 95 percentile: 0.16ms Threads fairness: events (avg/stddev): 415861.0000/0.00 execution time (avg/stddev): 178.9646/0.00 

ディスクサブシステムのパフォーマンスの尺度として、平均データ転送速度の値（この例では21.659Mb /秒）を使用できます。

このテストが私のサーバーで示したことを見てみましょう：



注：

• すべてのテスト済みサーバーでの疑わしい低速値が顕著
• NUC i5にssdディスクがインストールされています。テストを何度実行しても、データ転送速度の値は常に1.5〜2 Mb /秒の範囲にあります。
• 私の作業中のssd搭載MacBook Pro 2015では、このテストの速度値は140Mb /秒です8-）

MySQL OLTPテスト

テストでは、MySQLサーバーのトランザクションの速度をチェックし、各トランザクションは読み取りと書き込みの両方のリクエストで構成されます。

my.cnfのサーバー設定を変更し、再起動して一連のテストを実行すると非常に便利です。パフォーマンスの変化をすぐに確認できます。

テストの準備：
$ sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=pass prepare


テスト実行：
$ sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --mysql-password=pass --max-time=60 --oltp-read-only=off --max-requests=0 --num-threads=8 run


--oltp-read-onlyパラメーターをonに設定すると、読み取り要求のみが実行され、スレーブデータベースなどのモードでのDBMSの速度を評価できます。

試験結果：

 OLTP test statistics: queries performed: read: 564158 write: 0 other: 80594 total: 644752 transactions: 40297 (671.57 per sec.) deadlocks: 0 (0.00 per sec.) read/write requests: 564158 (9402.01 per sec.) other operations: 80594 (1343.14 per sec.) Test execution summary: total time: 60.0040s total number of events: 40297 total time taken by event execution: 479.8413 per-request statistics: min: 1.14ms avg: 11.91ms max: 70.93ms approx. 95 percentile: 15.54ms 

レポートで最も興味深いパラメーターは、1秒あたりのトランザクション数（1秒あたりのトランザクション数）です。

このテストがサーバー上でどのように示されたか：



注：

• MySQLの構成はすべてのサーバーで同じでした
• 驚くべきことに、A3サーバーとG2サーバーの間に大きな違いはありません。
• G2に匹敵するNUC i5

PostgreSQLのパフォーマンスを測定する方法は？

残念ながら、sysbenchツールにはPostgreSQL用の組み込みテストツールがありません。 ただし、pgbenchユーティリティを使用できるため、これはまったく気になりません。

追加情報：
www.postgresql.org/docs/devel/static/pgbench.html

デフォルトのパフォーマンステストスクリプトは、次のトランザクションを繰り返し実行します。

 BEGIN; UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); END; 

テストデータを作成するには、次のコマンドを実行します。
$ pgbench -h localhost -U test_user -i -s 100 test


テストを実施します。
$ pgbench -h localhost -U test_user -t 5000 -c 4 -j 4 test


コマンドキーは、4つのクライアントが4つのスレッドで5,000のトランザクションを実行することを意味します。 その結果、20,000件のトランザクションが完了します。

結果：

 starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 query mode: simple number of clients: 4 number of threads: 4 number of transactions per client: 5000 number of transactions actually processed: 20000/20000 latency average: 0.000 ms tps = 3350.950958 (including connections establishing) tps = 3357.677756 (excluding connections establishing) 

ここで最も重要なことはtpsです。

残念ながら、異なるサーバーでの比較テストはありません:)

しかし、PHPのパフォーマンスはどうですか？

sysbenchで十分にプレイし、多くのサーバーのCPUでキロワットのエネルギーを消費したため、ランダムサーバーのパフォーマンスを迅速かつ非常に適切に評価することを学びました。これにより、このサーバー上のWebアプリケーションのパフォーマンスの専門家による予測が可能になります。

ただし、sysbenchが良好な結果を示した状況があり、このサーバー上のphpアプリケーションは絶対に平凡なパフォーマンスインジケーターを示します。

もちろん、次のようなパラメーター：

• PHPバージョン
• 加速器
• PHPのコンパイル方法と方法
• 有効化される拡張機能

インストールが簡単で、起動後にサーバー上の現在のPHPの理解可能なパフォーマンスメトリックを生成するツールが必要です。 さらに、このツールがディスクサブシステム（またはネットワーク）のパフォーマンスの影響を受けないようにしたかったのです。プロセッサ+メモリリンクでのPHPインタープリターの動作のみを測定しました。

単純なグーグル/思考は、次のようなアイデアにつながりました。

• 既存のツールはありません
• 独自の参照アルゴリズム（スクリプト）を記述する必要がある
• アルゴリズムの不変性により、得られた結果を比較できます

行われた： github.com/florinsky/af-php-bench

スクリプトはpharアーカイブにコンパイルされるため、任意のサーバーでのダウンロードと実行がはるかに簡単になります。

実行するPHPの最小バージョンは5.4です。

実行するには：
$ wget github.com/florinsky/af-php-bench/raw/master/build/phpbm.phar

$ php phpbm.phar


スクリプトは、3つのグループに分けられた10個のテストを実行します。

• 最初のグループは一般的な操作です（ループ、ランド、オブジェクトの作成/削除）
• テストの2番目のグループは、文字列関数、内破/爆発、ハッシュ計算をチェックします
• 第三-配列を操作する
• すべての測定は数秒で実行されます。

テストレポート：

 [GENERAL] 1/10 Cycles (if, while, do) ...................... 6.72s 2/10 Generate Random Numbers ..................... 3.21s 3/10 Objects ..................................... 4.82s Time: .. 14.76 [STRINGS] 4/10 Simple Strings Functions ................... 13.09s 5/10 Explode/Implode ............................ 15.90s 6/10 Long Strings ............................... 30.37s 7/10 String Hash ................................ 23.57s Time: .. 82.93 [ARRAYS] 8/10 Fill arrays ................................ 22.32s 9/10 Array Sort (Integer Keys and Values) ....... 17.17s 10/10 Array Sort (String Keys and Values) ........ 14.29s Time: .. 53.79 TOTAL TIME: . 151.47 

このスクリプトにより、このサーバーでのPHPの全体的なパフォーマンス（合計時間）を評価できるだけでなく、その構成要素を確認することもできます。 平凡な全体的な結果が1つのテストのみによって形成されることを繰り返し見てきました。どこかで遅い乱数ジェネレーターであるかもしれず、どこかで長い行で動作するかもしれません。

結果ページ（https://github.com/florinsky/af-php-bench/blob/master/RESULTS.md）で、受け取ったレポートを記録し、それらを共通のテーブルにグループ化しました。 時々結果は驚くべきです:)

おわりに

上記のツールを使用すると、測定の時点でのみサーバーのパフォーマンスを評価できます。 サーバーの動作は、並列プロセスの影響を受ける可能性があることを理解する必要があります。 そして、測定結果が良い結果を示したとしても、それが常にそうなるという意味ではありません。

この問題は、すでに完全に動作しているクライアントサーバーを分析している場合に特に深刻です。 どのcronタスクが実行されているか、どのプロセスが長いgzip / tarを有効にするためにイベントを待機して待機しているのかわかりません。また、アンチウイルス/スパムフィルターと、謎の1つが発生するダースの仮想マシンがあります。

Atopおよびiostatは、時間の経過に伴うサーバーの動作を分析するのに役立ちます。 統計は数日間（またはそれ以上）蓄積され、その後は表示できます。

頂上

ファイルへのデータの書き込み：
$ atop -w /tmp/atop.raw 1 60


エントリを読む：
atop -r /tmp/atop.raw


iostat

CPU負荷測定：
$ iostat -c 1


結論：

 %user %nice %system %iowait %steal %idle 82.21 0.00 17.79 0.00 0.00 0.00 79.05 0.00 20.70 0.00 0.00 0.25 80.95 0.00 19.05 0.00 0.00 0.00 80.95 0.00 19.05 0.00 0.00 0.00 80.85 0.00 18.91 0.25 0.00 0.00 ... 

ディスクサブシステムの負荷の測定：
$ iostat -xd /dev/sda 1


結論：

 rkB/s wkB/s await r_await w_await svctm %util 0.00 2060.00 4.05 0.00 4.05 3.98 95.60 0.00 2000.00 3.97 0.00 3.97 3.95 96.40 0.00 1976.00 3.92 0.00 3.92 3.92 95.60 0.00 2008.00 3.95 0.00 3.95 3.93 96.00 0.00 2008.00 3.92 0.00 3.92 3.92 96.80 0.00 2020.00 4.03 0.00 4.03 4.00 97.60 0.00 2016.00 3.97 0.00 3.97 3.97 97.20 ... 

そして、もちろん、Muninなどを使用して、サーバーから統計を長い時間順に収集することができます。

ご清聴ありがとうございました！