パフォーマンス テストを行う際には、パフォーマンス テスト内のさまざまな側面に関連し、誤解されることが多いため、”同時実行” という用語を理解することが重要です。 エンドユーザーのデバイスでウェブサイトがどのように動作しているか疑問に思ったことはありますか? または、 Webサイトのトラフィックを増やすためにどのように計画しますか? または、一見目に見えないがビジネス全体に影響を与えるWebサイトの 問題を解決する 方法さえありますか? これらの質問に対する答えは、パフォーマンス テストです。
パフォーマンステストは永遠に存在していますが、 毎日新しいテクノロジーで進化しています。 基本的に、パフォーマンステストは、 スクリプトを使用してWebサイトと対話する実際のユーザーをシミュレートすることによって行われます。 次に、このインタラクションデータがキャプチャおよび分析され、応答時間、アクセシビリティ、信頼性、稼働時間、リソース使用量、スケーラビリティなど、Webサイトとアプリケーションのパフォーマンスのさまざまな側面に関する洞察が得られます。 パフォーマンス テストは、Web サイトがパフォーマンス基準を持つ安定した状態にあり、必要に応じてどのように改善および拡張するかを確認するために行われます。 さらに重要なことに、予測されるワークロードの下でシステムがどのように実行されているかに関する有用なデータを提供します。 パフォーマンステストでは、複数の要求が同時に行われた場合の不整合、非効率性、およびユーザビリティの問題も明らかになります。
基本的なパフォーマンスの問題とメトリック
最初のステップとして修正すべきパフォーマンスの問題を見てみましょう。
読み込み時間
アプリケーションの読み込み時間とは、 ユーザーがアクションを実行できるようになる前に、Webサイト、アプリケーション、または単一のページを完全に読み込むのにかかる時間です。 遅延の毎秒と同様に、ユーザーはウェブサイトから目をそらし、収益を失うことは非常に重要です。
応答時間
応答時間は、ユーザーの活動またはトランザクションに対するサーバーの応答を指します。 応答時間が多いほど、ユーザーのエクスペリエンスがイライラします。
リソース使用率とボトルネック
Webサイトまたはアプリケーションは、 トラフィックやリソースの需要が高い場合に、管理可能なリソース割り当てとともに、リソースを効率的に利用する必要があります。 CPU、メモリ、ネットワークなどのリソースは、多くのシナリオでボトルネックとなり、アプリケーション全体が停止する可能性があります。
スケーラビリティ
ウェブサイトまたはアプリケーションは、通常の需要時または特別なイベントで予想されるトラフィックを処理できる必要があります。 高需要を維持できない場合、スケーラビリティの問題が発生し、ロード テストを使用して分析および修正する必要があります。
実際のシナリオ
これらの根本的な問題とは別に、業績に直接関連するビジネス固有のユースケースは数多くあります。 たとえば、取引アプリケーションがある場合、Webサイトの速度を向上させることは一度に行われる作業ではないので、ビジネスやユーザーに金銭的な損失を回避するために、わずか数ミリ秒で機会を作ったり壊したりできる応答時間を積極的に短縮する必要があります。
以下のリストは、パフォーマンス テスト中に測定、監視、および分析するために必要ないくつかの基本的なパラメータで構成されています。
- 応答時間
- 1 秒あたりの CPU 割り込み
- ネットワーク出力待ち行列の長さ
- 1 秒あたりのネットワーク バイトの合計
- スループット
- 最大アクティブ セッション数
- ヒット率
- データベース ロック
- ガベージ コレクション
- CPU 使用率
- メモリ使用量
- ディスク I/O
- ネットワーク帯域幅
- メモリページ/秒
- ページ フォールト/秒
- 同時実行 HTTP ベンチマーク
- 同時ユーザー数
同時接続 HTTP 接続と同時実行ブラウザー対同時ユーザー数
同時実行 HTTP
同時実行 HTTP は、任意の時点で行われた HTTP 要求を参照します。 たとえば、有効なセッションを持つ 10000 人のユーザーが存在し、100 人のユーザーが HTTP 経由で同じリソースを読み取ることを要求しているとしますが、同時に HTTP 要求が 100 回発生したとします。
同時実行ブラウザ
同時実行ブラウザとは、任意の時点で有効なセッションを持つブラウザの数を指します。 任意の数の要求をいつでもサーバーに送信できます。
同時ユーザー数
同時ユーザーは、サーバーとの有効なセッションを持つユーザーを、いつでも同じタスクを実行します。
通常、同時ユーザーと同時ユーザーはどちらも同じ意味で使用されるため、混乱しますが、パフォーマンステストでは意味が異なります。 例を見てみましょう。
サーバーとの有効なセッションを持つ 1,000 人の異なるユーザーがいるとします。 これらの各ユーザーは、サインイン、チェックアウト、メッセージング、ショッピングなどのさまざまな操作を実行しています。 これらは同時ユーザーと呼ばれ、基本的にはサーバー内で有効なセッションを持つユーザーの数です。 現在、この 1000 人のユーザーのうち 100 人が、同じ時点でチェックアウト操作を実行している可能性があります。 その後、これらの100人のユーザーが同時ユーザーになります。 同時ユーザーは、同時ユーザーよりも非常に少なくて、頻繁に発生しません。
ロード テスト: 速度、スケーラビリティ、安定性
ロード テストは、高トラフィック負荷の下で Web サイト/アプリケーションをテストするための最も重要な種類のパフォーマンス テストの 1 つです。 このテストから収集されたデータは分析され、多数の実際のユーザーがウェブサイトにアクセスしたときに発生する可能性のある問題を把握するために予測されます。 Web サイト/アプリケーション インフラストラクチャの将来のスケーラビリティを実現するために、ボトルネックを解消し、トランザクションを最適化すると便利です。 いくつかの基本的な ロード テストの種類、それらの違い、およびそれらの重要性を見てみましょう。
HTTP ロード テスト
HTTP ロード テストは、通常、サーバーが処理できる同時 HTTP 要求の数を識別するために行われます。 また、1 秒あたりの最大要求数としてアプローチすることもできます。 詳細レベルでは、読み取り、書き込み、通勤など、さまざまな種類の要求が存在する場合があります。 特定の要求ごとに制限を見つけることにより、どのような最適化とリソース計画を実行する必要があるかを詳しく把握できます。 たとえば、読み取り HTTP 要求の場合は 1 秒あたりの要求数が多くなる可能性がありますが、集中型の要求を通勤する場合は、おそらくはるかに少なくなります。
Web ページのロード テスト
Web ページロードテストは、任意の単一ページのロード時間に対して実行されます。 たとえば、eコマースWebサイトがある場合、個々の製品ページの読み込み時間、カートページの読み込み時間、チェックアウトページの読み込み時間を確認して、 顧客体験を強化および改善する必要があります。 製品のページの読み込みは問題ありませんが、カートページの最適化を無視すると、売上損失が生じることは間違いありません。
Web アプリケーションロードテスト
Web アプリケーションのロード テストは、Web アプリケーションの最初の負荷を測定するために行われます。 これは、他のすべてのページに対して行うページの読み込み時間とは異なります。 ウェブ アプリケーションが起動すると、最終的に読み込まれる前に、さまざまなリソースが取り出され、サイト全体のサービスがほとんど開始されず、サードパーティのサービスが呼び出されます。 Web アプリケーションの読み込み時間を最適化して、チャーンを防ぐには、最初の焦点を当てる必要があります。
最終考察: 同時 HTTP 対 同時ブラウザー対同時ユーザー数
ロード テストは、開発者や設計者が最適化やリソース計画に役立つ必要があります。 ピークトラフィックを想定している Web アプリケーションの場合、さらに重要になります。 ロード テストとは別に、サードパーティサービスのアクセシビリティ、速度、アップタイムについて、Web サイトやアプリケーションを 定期的に監視することも重要 です。 異なる場所から Web サイトやアプリケーションをロード テストして監視し、ユーザーが場所から特定のパフォーマンスの問題を引き起す可能性があるため、その機能をさらに改善することを忘れないでください。 LoadViewのようなソリューションを使用すると、数百から数千の同時 HTTP 接続またはブラウザーを使用して、すべての Web ページ、アプリケーション、Web サービス、サーバー、および API を簡単にロードできます。
LoadView の無料試用版を試して、無料のロード テストを受けてください。 または、パフォーマンスエンジニアによるライブデモをスケジュールして、LoadViewプラットフォームの完全なウォークスルーを行い、プラットフォームが提供するすべての機能と利点を確認してください。