他の多くの人と同じように、「Web サーバーが処理できる同時要求の数」をテストしたいと思います。
abまたはのようなツールを使用しsiege、Apache Web サーバー / mysql データベース / php スクリプトに実際の使用状況を表すクエリを実行することによって、実際のユーザーによる実際の使用状況と比較して、得られる結果はどの程度代表的なものになるでしょうか?
たとえば、ユーティリティでテストすると、すべてのトラフィックは単一の IP から来ているのに、実際の使用は多くの異なる IP アドレスから来ているということですか? これは世界の違いを説明していますか？
Web サーバーが 1 秒あたり 1000 リクエストを処理できると言う場合ab、これは Web サーバーが実際のユーザーからの 1 秒あたり 1000 リクエストを処理すると言うことに直接転用できますか?
私はこれがふわふわした領域であることを知っているので、より具体的で直接的な回答が得られるほど良い. 古い「場合による」はあまり役に立ちません:)
申し訳ありませんが、ここでは「場合による」が最良の答えです。
まず、この質問に答える上で最も価値のあるツールは、ab でも siege でも JMeter (私のお気に入りのオープン ソース ツール) でもなく、スプレッドシートです。
システムが処理できるリクエストの数は、最初にぶつかったボトルネックによって決まります。これらのボトルネックの一部はハードウェア/インフラストラクチャ (帯域幅、CPU、負荷分散スキームの有効性) であり、一部は「既製の」ソフトウェアとその構成方法 (たとえば、静的ファイルを提供する Apache の機能) です。ソフトウェア (PHP スクリプトとデータベース クエリの実行効率)。一部のボトルネック リソースは制御できない場合があります。たとえば、ヨーロッパまたは米国でホストされているほとんどのサイトは、中国からアクセスすると速度が低下します。
スプレッドシートを使用してユーザー ジャーニーをモデル化しました。これは、特定のケースに完全に依存しますが、ユーザー ジャーニーは次のようになります。
ほとんどのサイトは、多くのユーザー ジャーニーをサポートしています。いつでも、これらのユーザー ジャーニーの組み合わせは大きく異なる可能性があります。
ユーザージャーニーごとに、訪問者の要求の性質を評価します。たとえば、「ホームページにアクセス」は「20 個の静的ファイルと 1 つの PHP スクリプトをダウンロードする」であり、「新規ユーザーとして登録する」には「1 つの PHP スクリプト」が必要な場合があります。 、ただしかなり複雑なデータベース スクリプトのセットを使用します。
このプロセスは、タイプごとのリクエスト数を示すスプレッドシートの一連の行として終了します。精度を上げるために、各動的ページ (PHP スクリプト) を独自の要求として扱う必要があるかもしれませんが、通常はすべての静的アセットをひとまとめにします。
これにより、一連の仮定に基づいてテストするためのベースラインが得られます。「20% の新規ユーザー、50% のリピーター ユーザー、10% のホームページのみ、20% の完全な購入経路、20% の放棄バスケット」または思いついたユーザー ジャーニーを表す負荷テスト スクリプトを作成できるようになりました。
ジャーニーを含む負荷テスト スクリプトを作成して実行します。理想的には、複数の場所から (クラウド プロバイダーから Jmeter を実行する安価な方法がいくつかあります)。応答時間を測定し、10% 以上のケースで、最も遅い要求の応答時間が品質しきい値 (通常は 3 秒をお勧めします) を超えている場所を確認します。
ユーザー ジャーニー間の分割を変えてみてください。たとえば、広告キャンペーンによって多くの新規登録が促進される場合があります。通常、少なくとも 3 つまたは 4 つの異なる混合物をお勧めします。
ユーザー ジャーニーのバリエーションのいずれかが平均を大幅に下回る結果 (15% 以上) をもたらす場合、それはおそらく最悪のシナリオです。
それ以外の場合は、結果を平均すると、これがサポートできるリクエストの最小数であることが、ある程度の確実性でわかります。テストできるユーザー ジャーニーのバリエーションが多いほど、数値が正確であることが確実になります。「最小」とは、少なくともこの数のユーザーを管理できると合理的に確信できることを意味します。これだけ多くのユーザーを処理できるという意味ではありません。微妙な違いですが、重要な違いです。
ほとんどの Web アプリケーションでは、ボトルネックは動的なページ生成です。静的ファイルを提供する Apache の機能やホスティング プロバイダーの帯域幅をテストする意味はほとんどありません。これは「何か忘れていないか」テストとしては良いのですが、PHP スクリプトをテストすることで、はるかに多くの価値を得ることができます。
これを行う前に、PHP ファイルだけで「ボトルネックを探す」ことをお勧めします。上記で概説したプロセスでは、ボトルネックがどこにあるかはわかりません。ボトルネックが 1 つあるだけです。PHP である可能性が最も高いため (もちろん、データベースの呼び出しなど、PHP から実行するすべてのことも)、パフォーマンスをテストするためにソリューションをインストルメント化することは、通常は良い考えです。
また、Yslow などのツールを使用して、HTTP/HTML の設定が最適化されていることを確認する必要があります。静的アセットのキャッシュ ヘッダーを設定すると、帯域幅の請求に大きな影響があり、エンド ユーザーが認識するパフォーマンスが向上する可能性があります。\
短い答えはノーです。おそらくそうではありません。
ab友人は、ローカル マシンから実行する場合、ネットワーク ラグ/帯域幅チョークの影響を受けません。
さらに、実際のすべてのリクエストには、DB アクセス/ロード、ファイル インクルードなど、さまざまなレベルの処理が必要です。
さらに、これには、実行中の他のバックグラウンド プロセスによるサーバーの負荷が考慮されていません。
siege実際の結果に近い結果を得るには、典型的なユーザーの行動を分析し、ユーザーがアクセスしている URL を含む URL ファイルを作成し、ランダムな遅延で実行することをお勧めします。この結果を本番環境に直接転送することはできませんが、独自の結果で得られる最も近い結果です。Web アプリのパフォーマンスをテストする Web サービスを試すこともできますが、複雑なテストが必要な場合は通常有料です
しかし、「場合による」と言ってもあまり役に立ちません。有効な答えが「場合による」だけではないという意味ではありません。それは一種だからです。
単一の IP は多くのアプリケーションにとって問題にならないので、最初に心配することはありません。しかし、次のようになる可能性があります: IP ごとに 1 回複雑な統計を行う場合 (たとえば、うまく設計できなかったテーブルに情報を保存する場合)、これはテストで 1 回だけ行うことを意味するため、悪い結果が得られます。実際のユーザーが迷惑なほど異なる IP を使用する時期
すべてのリクエストが低速回線から送信された場合 (これらのすべてのリクエストを実行しているため低速である可能性があります)、深刻なテストは行われません。基本的に、着信トラフィックがテストシステムの接続で処理できる以上になると予想される場合は、ドリフトが発生します。同じことがCPU使用率などにも当てはまります。
たとえば、リクエストがすべてのページにヒットしているが、ユーザーが特定の 1 つのページにしかヒットしていない場合、明らかに異なる結果が得られます。頻度についても同じことが言えます。キャッシュのようなものをすべて活用できる順序でページにアクセスすると (クエリ キャッシュはこれでは扱いにくいものですが、memcached や varnish などのレイヤーも同様です)、やはりうまくいきません。あなたが探すことができる最も簡単なことはdelay、包囲テストを設定できることですが、他にも考慮したいことがたくさんあります.
良いテストを書くのは難しく、テストが良ければ良いほど、より近づくことができます。ただし、システム、ユーザー、およびテストを理解する必要があります。「場合による」と言うよりも、本当に言うことはあまりありません。