パフォーマンステスト

パフォーマンステストの結果に影響を与える要因は何ですか？

• クライアントからサーバーへのネットワーク遅延（内部ネットワークまたはローカルでのテストが推奨）
• クライアントからサーバーへの帯域幅（内部ネットワークまたはローカルでのテストが推奨）
• HTTP keep-aliveの有効化の有無（有効化を推奨）
• 十分な並行数（外部ネットワークでのテストでは可能な限り多くの並行数を開始することを推奨）
• サーバープロセスの適切な数（helloworldビジネスプロセスについては、CPUの数と同じ数を、データベースビジネスプロセスについてはCPUの4倍以上を推奨）
• ビジネスのパフォーマンス自体（外部データベースの使用など）

HTTP keep-aliveとは何ですか？

HTTP Keep-Aliveメカニズムは、単一のTCP接続で複数のHTTPリクエストとレスポンスを送信するための技術です。これはパフォーマンステストの結果に大きく影響し、keep-aliveを無効にするとQPSが大幅に減少する可能性があります。
現在、ほとんどのブラウザはデフォルトでkeep-aliveを有効にしており、つまり、特定のHTTPアドレスにアクセスした後、接続を一時的に閉じずに次のリクエストでその接続を再利用してパフォーマンスを向上させます。
パフォーマンステスト時には、keep-aliveを有効にすることを推奨します。

HTTP keep-aliveを有効にするにはどうすればよいですか？

abツールを使用する場合は、-kパラメータを追加する必要があります。例：ab -n100000 -c200 -k http://127.0.0.1:8787/。
apipostでは、gzipヘッダーを返すことによってkeep-aliveを有効にする必要があります（apipostのバグのため、以下を参照してください）。
その他のパフォーマンステストプログラムでは、通常はデフォルトで有効になっています。

外部ネットワークでのパフォーマンステスト時になぜQPSが低いのですか？

外部ネットワークの遅延が大きいため、QPSが低くなるのは正常な現象です。たとえば、baiduページのパフォーマンステストではQPSが数十にしかなる可能性があります。
ネットワーク遅延の影響を排除するためには、内部ネットワークやローカルでのテストが推奨されます。
外部ネットワークでテストする必要がある場合は、帯域幅を十分に確保するために並行数を増やすことによってスループットを増加させることができます。

nginxプロキシ後の性能が低下するのはなぜですか？

nginxを実行すると、システムリソースを消費します。同時に、nginxとwebmanの間の通信も一定のリソースを消費します。
ただし、システムリソースは限られており、webmanはすべてのシステムリソースを取得することができません。そのため、システム全体のパフォーマンスが一部低下することは正常な現象です。
nginxプロキシによるパフォーマンスへの影響をできるだけ減らすには、nginxのログを無効にする（access_log off;）こと、nginxからwebmanへのkeep-aliveを有効にすることを検討することをお勧めします。nginxプロキシを参照してください。
また、httpsとhttpを比較すると、httpsのほうがより多くのリソースを消費します。なぜなら、httpsではSSL/TLSハンドシェイクやデータの暗号化・復号化が必要であり、パケットサイズが大きくなり帯域幅を使用するためです。これらはパフォーマンスの低下につながる可能性があります。
パフォーマンステストにおいて、短い接続（HTTP keep-aliveを無効にしている）を使用する場合、各リクエストに追加のSSL/TLSハンドシェイク通信が必要となり、性能が大幅に低下します。httpsのパフォーマンステストを行う場合は、HTTP keep-aliveを有効にすることをお勧めします。

システムがパフォーマンス上限に達したかどうかを知る方法は？

通常、CPUが100％に達したときにシステムのパフォーマンスが上限に達したと言えます。CPUに余裕がある場合は、まだ限界に達していないと言えます。この場合、適切な並行数を増やすことでQPSを向上させることができます。
しかし、並行数を増やしてもQPSが改善されない場合は、webmanプロセス数が不足している可能性があります。この場合は、webmanプロセスを適切に増やしてみてください。それでも改善されない場合は、帯域幅が十分であるかどうかを確認してください。

なぜ私のパフォーマンステスト結果でwebmanのパフォーマンスがgoのginフレームワークよりも低いですか？

techempowerによると、webmanは純粋なテキスト、データベースのクエリ、データベース更新などすべての指標でginよりも約倍の性能を示しています。
異なる結果が出る場合、おそらくwebmanでORMを使用していることによる性能の損失が発生している可能性があります。webman+ネイティブPDOとgin+ネイティブSQLを比較してみてください。

webmanでORMを使用した場合のパフォーマンスの減少はどれくらいですか？

以下は一連のパフォーマンステストデータです。

環境

• Alibaba Cloudの4コア4Gサーバー、10万件のレコードからランダムに1つのデータをJSONで返す。

ネイティブPDOを使用した場合

• webmanのQPSは17,800です

LaravelのDb::table()を使用した場合

• webmanのQPSは9,400に低下します

LaravelのModelを使用した場合

• webmanのQPSは7,200に低下します

thinkORMの結果も同様で、大きな違いはありません。

Note:
ORMを使用するとパフォーマンスが低下する可能性がありますが、ほとんどのビジネスにとっては十分なパフォーマンスです。開発効率、保守性、パフォーマンスなど、複数の基準に基づいてバランスを見極めるべきです。

apipostでパフォーマンステストを行うとなぜQPSが低いですか？

apipostのパフォーマンステストモジュールにバグがあり、サーバーがgzipヘッダーを返さない場合はkeep-aliveを維持できないため、パフォーマンスが大幅に低下します。
解決方法として、データを圧縮してgzipヘッダーを追加して返すことが挙げられます。例えば、以下のように記述します。

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

これ以外にも、apipostでは満足のいく圧力をかけることができない場合があり、同じ並行数の場合、apipostを使用した場合はQPSがabよりも約50％低くなることがあります。
パフォーマンステストにはapipostの代わりにab、wrk、または他の専門のパフォーマンステストソフトウェアを使用することをお勧めします。

適切なプロセス数を設定する

webmanではデフォルトでCPU×4のプロセス数が開かれます。ネットワークIOがないhelloworldビジネスのパフォーマンステストでは、プロセス数をCPUコア数と同じにした場合が最適です。これにより、プロセスの切り替えオーバーヘッドを減らすことができます。
一方、データベースやRedisなどのブロッキングIOビジネスの場合、プロセス数はCPUの3～8倍に設定することができます。なぜなら、より多くのプロセスが並行性を高め、ブロッキングIOに対してはプロセス切換えオーバーヘッドをほとんど無視できるためです。

パフォーマンステストの一般的な参考範囲

クラウドサーバー 4コア 4G、16プロセス、ローカル/内部ネットワークでのテスト

第三者techempowerのベンチマークデータ

パフォーマンステストのコマンド例

ab

# 100,000リクエスト 200並行 keep-aliveを有効化
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100,000リクエスト 200並行 keep-aliveを無効化
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200並行で10秒間パフォーマンステスト（keep-aliveはデフォルトで有効）
wrk -c 200 -d 10s http://example.com