1

テスト ページを読み込んで JavaScript をレンダリングしたいと思います。この問題を解決する可能性のあるアプリケーションには 3 つのカテゴリがあるようですが、3 つすべてが的外れです。

1) Jmeter、apachebench、tsung、Grinder、Iago うまくいかない理由: javascript をレンダリングしません。これらは便利なツールですが、この目的には使用できません。

2) Watir、Selenium これらのツールは優れており、実際のブラウザーを使用し、javascript / ajax をレンダリングしますが、残念ながら、これらは主に機能テスト用に設計されており、パフォーマンス テスト用ではありません。これらを負荷テストに使用する独自のアプリを作成することもできますが、すべてのパフォーマンス メトリックを収集して集計するのは大変な作業です。

最初の 2 つのタイプの Web パフォーマンス テストの組み合わせがあれば、それは素晴らしいことです。

3 番目のオプションは、この問題を解決しますが、残念ながら料金を支払う必要があります。3) Web 負荷テスト サービス Keynote Load Pro、BrowserMob などのサービスは優れており、実際のブラウザーを使用して JavaScript をレンダリングする際の問題を解決します。唯一の問題は、いまいましい負荷テストを実行するたびに 300 ドルも払いたくないということです (これは誇張ですが、使用する仮想ユーザーの数によって異なります)。

私がお金を出血させたくない限り、そのオプションは機能しません。

この問題を解決するテスト ハーネスはありませんか? まだ誰も解決していないオープンソース ツールが必要な大きな穴のように思えます。営利企業がこの分野を支配しています (また、フルタイムの開発者を雇って Selenium パフォーマンス テスト フレームワークを作成したいと考えている企業も)。

4

2 に答える 2

1

jmeter、ab、tsung などの良い点は、集計されたメトリックを比較的短時間で提供できることですが、javascript を実行することはできません。DOM の作成速度を測定することはできません。画像、JavaScript、スタイルなどの外部リソースは読み込まれません。それらは、ここでは当てはまらないストレステストに適しています。

Web パフォーマンスを測定するときは、次のことを知っておく必要があります。

  • あなたが本当に測定したいものは何ですか?- domLoading、、またはおそらくPerformance Timing Interfaceからの何かdomInteractivedomContentLoaded
  • どの統計的尺度を使用しますか? -p95 、中央。平均は最良の選択ではありません。
  • いつ?- テストを比較可能にするために、常に同時に実行します。
  • どの場所から?- あなたができる最善のことは、本番環境の近くにある専用サーバーを生成することです.
  • 結果についてどの程度自信を持ちたいですか?- サンプル データ サイズを選択します。たとえば、95% の信頼区間で 3% の誤差範囲を受け入れる場合は、1067 を選択します。

このような合成パフォーマンス測定を行うには、 https://github.com/msn0/sweterを使用できます。timeToFirstBytedomInteractiveおよびdomCompleteタイミングを測定します。常に同時にテストを実行するようにスケジュールできます。Sweter は、生データを ElasticSearch、コンソール、json ファイル、または任意の場所にレポートできます。

別のトピックはReal User Measurementsです。NewRelicなど、そのための優れたツールが既にあります。

于 2015-04-16T09:36:42.643 に答える