ページを選択

パフォーマンス テストを行う際には、パフォーマンス テスト内のさまざまな側面に関連し、誤解されることが多いため、”同時実行” という用語を理解することが重要です。 エンドユーザーのデバイスでウェブサイトがどのように動作しているか疑問に思ったことはありますか? または、ウェブサイトのトラフィックを増やす方法を計画していますか? あるいは、一見目に見えないが、ビジネス全体に影響を与えるウェブサイトの問題を解決する方法も? これらの質問に対する答えは、パフォーマンス テストです。

パフォーマンス テストは、永遠に続いていますが、新しいテクノロジを使用して日々進化しています。 パフォーマンス テストの中核となるのは、実際のユーザーをシミュレートしてスクリプトを使用して ウェブ サイトとやり取りすることです。 この対話データは、応答時間、アクセシビリティ、信頼性、稼働時間、リソースの使用、スケーラビリティなど、ウェブ サイトやアプリケーションのパフォーマンスのさまざまな側面に関する洞察を得て、取得および分析されます。 パフォーマンス テストは、ウェブ サイトがパフォーマンス基準を持つ安定した状態にあり、必要に応じてどのように改善および拡張するかを確認するために行われます。 さらに重要なのは、予測されたワークロードでのシステムのパフォーマンスに関する有用なデータを提供することです。 パフォーマンス テストでは、複数の要求が同時に行われる場合、不整合、非効率性、およびユーザビリティの問題も明らかになります。

 

基本的なパフォーマンスの問題とメトリック

最初のステップとして修正すべきパフォーマンスの問題を見てみましょう。

 

読み込み時間

アプリケーションの読み込み時間とは、ユーザーが何らかの操作を実行できる前に、ウェブ サイト、アプリケーション、または単一ページを完全に読み込むためにかかった時間です。 遅延の毎秒と同様に、ユーザーはウェブサイトから目をそらし、収益を失うことは非常に重要です。

 

応答時間

応答時間は、ユーザーの活動またはトランザクションに対するサーバーの応答を指します。 応答時間が多いほど、ユーザーのエクスペリエンスがイライラします。

 

リソース使用率とボトルネック

ウェブ サイトまたはアプリケーションは、リソースのトラフィックや需要が高い場合に、管理可能なリソース割り当てと共に効率の良いリソースを利用する必要があります。 CPU、メモリ、ネットワークなどのリソースは、多くのシナリオでボトルネックとなり、アプリケーション全体が停止する可能性があります。

 

スケーラビリティ

ウェブサイトまたはアプリケーションは、通常の需要時または特別なイベントで予想されるトラフィックを処理できる必要があります。 高需要を維持できない場合、スケーラビリティの問題が発生し、ロード テストを使用して分析および修正する必要があります。

 

実際のシナリオ

これらの根本的な問題とは別に、業績に直接関連するビジネス固有のユースケースは数多くあります。 たとえば、取引アプリケーションがある場合、ウェブ サイトの速度を向上させることは一度に行われる作業ではないので、ビジネスやユーザーに金銭的な損失を回避するために、わずか数ミリ秒で機会を作ったり壊したりできる応答時間を積極的に短縮する必要があります。

以下のリストは、パフォーマンス テスト中に測定、監視、および分析するために必要ないくつかの基本的なパラメータで構成されています。

  • 応答時間
  • 1 秒あたりの CPU 割り込み
  • ネットワーク出力待ち行列の長さ
  • 1 秒あたりのネットワーク バイトの合計
  • スループット
  • 最大アクティブ セッション数
  • ヒット率
  • データベース ロック
  • ガベージ コレクション
  • CPU 使用率
  • メモリ使用量
  • ディスク I/O
  • ネットワーク帯域幅
  • メモリページ/秒
  • ページ フォールト/秒
  • 同時実行 HTTP ベンチマーク
  • 同時ユーザー数

 

同時接続 HTTP 接続と同時実行ブラウザー対同時ユーザー数

 

同時実行 HTTP

同時実行 HTTP は、任意の時点で行われた HTTP 要求を参照します。 たとえば、有効なセッションを持つ 10000 人のユーザーが存在し、100 人のユーザーが HTTP 経由で同じリソースを読み取ることを要求しているとしますが、同時に HTTP 要求が 100 回発生したとします。

 

同時実行ブラウザ

同時実行ブラウザとは、任意の時点で有効なセッションを持つブラウザの数を指します。 任意の数の要求をいつでもサーバーに送信できます。

 

同時ユーザー数

同時ユーザーは、サーバーとの有効なセッションを持つユーザーを、いつでも同じタスクを実行します。

通常、同時ユーザーと同時ユーザーはどちらも同じ意味で使用されるため、混乱しますが、パフォーマンステストでは意味が異なります。 例を見てみましょう。

サーバーとの有効なセッションを持つ 1,000 人の異なるユーザーがいるとします。 これらのユーザーはそれぞれ、サインイン、チェックアウト、メッセージング、ショッピングなど、さまざまな操作を実行しています。 これらは同時ユーザーと呼ばれ、基本的にはサーバー内で有効なセッションを持つユーザーの数です。 現在、この 1000 人のユーザーのうち 100 人が、同じ時点でチェックアウト操作を実行している可能性があります。 その後、これらの100人のユーザーが同時ユーザーになります。 同時ユーザーは、同時ユーザーよりも非常に少なくて、頻繁に発生しません。

 

ロード テスト: 速度、スケーラビリティ、安定性

ロード テストは、高トラフィック負荷の下で ウェブ サイト/アプリケーションをテストするための最も重要な種類のパフォーマンス テストの 1 つです。 このテストから収集されたデータは分析され、多数の実際のユーザーがウェブサイトにアクセスしたときに発生する可能性のある問題を把握するために予測されます。 ウェブ サイト/アプリケーション インフラストラクチャの将来のスケーラビリティを実現するために、ボトルネックを解消し、トランザクションを最適化すると便利です。 基本的なロード テストの種類、その違い、およびそれらの重要性について見てみましょう。

 

HTTP ロード テスト

HTTP ロード テストは、通常、サーバーが処理できる同時 HTTP 要求の数を識別するために行われます。 また、1 秒あたりの最大要求数としてアプローチすることもできます。 詳細レベルでは、読み取り、書き込み、通勤など、さまざまな種類の要求が存在する場合があります。 特定の要求ごとに制限を見つけることにより、どのような最適化とリソース計画を実行する必要があるかを詳しく把握できます。 たとえば、読み取り HTTP 要求の場合は 1 秒あたりの要求数が多くなる可能性がありますが、集中型の要求を通勤する場合は、おそらくはるかに少なくなります。

 

ウェブ ページのロード テスト

ウェブ ページロードテストは、任意の単一ページのロード時間に対して実行されます。 たとえば、e コマース ウェブ サイトを使用している場合、個々の製品ページの読み込み時間、カート ページの読み込み時間、チェックアウト ページの読み込み時間を確認して、顧客体験を向上および向上させます。 製品のページの読み込みは問題ありませんが、カートページの最適化を無視すると、売上損失が生じることは間違いありません。

 

ウェブ アプリケーションロードテスト

ウェブ アプリケーションのロード テストは、ウェブ アプリケーションの最初の負荷を測定するために行われます。 これは、他のすべてのページに対して行うページの読み込み時間とは異なります。 ウェブ アプリケーションが起動すると、異なるリソースを引き出し、サイト全体のサービスをほとんど開始し、サードパーティのサービスを呼び出して、最終的に読み込みます。 ウェブ アプリケーションの読み込み時間を最適化して、チャーンを防ぐには、最初の焦点を当てる必要があります。

 

最終考察: 同時 HTTP 対 同時ブラウザー対同時ユーザー数

ロード テストは、開発者や設計者が最適化やリソース計画に役立つ必要があります。 ピークトラフィックを想定している ウェブ アプリケーションの場合、さらに重要になります。 ロード テストとは別に、サードパーティサービスのアクセシビリティ、速度、アップタイムについて、ウェブ サイトやアプリケーションを 定期的に監視することも重要 です。 異なる場所から ウェブ サイトやアプリケーションをロード テストして監視し、ユーザーが場所から特定のパフォーマンスの問題を引き起す可能性があるため、その機能をさらに改善することを忘れないでください。 LoadViewのようなソリューションを使用すると、数百から数千の同時 HTTP 接続またはブラウザーを使用して、すべての ウェブ ページ、アプリケーション、ウェブ サービス、サーバー、および API を簡単にロードできます。

LoadView無料トライアルを試してみて、ロードテストクレジットで$ 20を受け取ります。 または、LoadViewプラットフォームを完全にウォークスルーするためのパフォーマンスエンジニアとの ライブデモをスケジュール して、プラットフォームが提供するすべての機能とメリットを確認してください!