Webアプリケーションでストレステストを実行しますか？

以前は、Microsoft Web Application Stress ToolとPylotを使用してWebアプリケーションのストレステストを行いました。簡単なホームページ、ログインスクリプト、およびサイトウォークスルー（eコマースサイトで、カートにアイテムをいくつか追加してチェックアウトする）を作成しました。

ほんの一握りの開発者でホームページを強く叩くだけでは、ほとんど常に大きな問題が見つかります。リリース後、第2ステージでさらにスケーラビリティの問題が表面化します。

私が使用したツールのURLは、Microsoft Homer（別名Microsoft Web Application Stress Tool）とPylotでした。

これらのツールによって生成されたレポートは、私にとってあまり意味がありませんでした。サイトがサポートできる同時負荷の種類を理解するために何時間も費やしました。最も愚かなバグとボトルネックが常に発生するため、常に価値がありました（たとえば、Webサーバーの設定ミス）。

あなたは何をしましたか、どのツールを使用しましたか、そしてあなたのアプローチでどのような成功を収めましたか？私にとって最も興味深い部分は、ストレステストアプリケーションによって報告された数からアプリがサポートできる同時ユーザーの数を計算するための、ある意味のある式を考え出すことです。

これがJMeterへの別の投票です。

JMeterは、Javaで記述されたオープンソースの負荷テストツールです。さまざまな種類のサーバー（Web、Webサービス、データベースなど、基本的に要求を使用するものすべて）をテストできます。

ただし、複雑なテストに取り掛かると、学習曲線は急になりますが、それだけの価値はあります。あなたはすぐに立ち上がって実行することができ、どのようなストレステストをしたいかに応じて、それはうまくいくかもしれません。

長所：

• Apacheプロジェクトのオープンソース/無料ツール（賛同を支援）
• 使い始めるのは簡単で、コアコンセプトを理解すると使いやすくなります。（つまり、リクエストの作成方法、アサーションの作成方法、変数の操作方法など）。
• 非常にスケーラブルです。11台のマシンでサーバーに負荷を発生させてテストを実行し、1時間あたり約100万ヒットのチューニングを行いました。それは多かった予想よりもセットアップ簡単でした。
• 活発なコミュニティと優れたリソースがあり、あなたが立ち上がって実行するのに役立ちます。最初にチュートリアルを読んで、しばらく遊んでください。

短所：

• UIはSwingで書かれています。（うわぁ！）
• JMeterは、サーバーから返された応答テキストを解析して機能します。したがって、何らかのJavaScriptの動作を検証しようとしているのであれば、運が悪いのです。
• プログラマーでない人にとっては、学習曲線は急です。正規表現に精通している場合は、すでにゲームをリードしています。
• サポートフォーラムには、愚かな質問をする（虚辞を挿入する）馬鹿が多数いますが、ドキュメントをざっと見ても簡単に解決できる愚かな質問があります。（「JMeterを使用してWindows GUIのストレステストを行う方法」が頻繁に表示されます）。
• 「そのまま」のレポートは、特に大規模なテストの場合、多くのことが望まれます。上記のテストでは、「xml-logfile」から「html」への変換の一部を実行するためのクイックコンソールアプリを作成する必要がありました。しかし、それは数年前だったので、これはもはや必要ないだろう。

私は使いました グラインダー。それはオープンソースで、かなり使いやすく、非常に構成可能です。これはJavaベースで、スクリプトにJythonを使用します。私たちはそれを.NET Webアプリケーションに対して実行したので、それがJavaのみのツールであるとは考えないでください（本来、どのWebストレスツールも、それが使用するプラットフォームに関連付けるべきではありません）。

私たちはそれでいくつかのきちんとしたことをしました...私たちはウェブベースのテレコムアプリケーションだったので、私が設定したクールな用途の1つは、ウェブアプリケーションを通して番号をダイヤルすることを模倣し、そして私たちが持っていた自動応答ツールを使いました（それは基本的にチュートリアルでした） RTC LCSサーバーに接続するためのMicrosoftのアプリ...これは、Microsoft Office Communicatorがローカルネットワークで接続するものです...その後、自動的に通話をピックアップするように変更されています）。これにより、The Hammer（またはそのようなもの）と呼ばれる高価な電話ツールの代わりにこれを使用できるようになりました。

とにかく、このツールを使用して、アプリケーションが高負荷でどのように保持されるかを確認しました。ボトルネックを見つけるのに非常に効果的でした。このツールには、リクエストの所要時間を示すレポートが組み込まれていますが、使用したことはありません。ログには、すべての応答とその他の情報、またはカスタムログを保存することもできます。

私はこのツールを強くお勧めします。価格的には非常に便利ですが、カスタムセットアップを行うことを期待しています（スクリプトを記録するプロキシが組み込まれていますが、セッションのようなものをキャプチャするにはカスタマイズが必要になる場合があります...わかっています。スレッドごとに一意のセッションを利用するようにカスタマイズする必要がありました）。

このパーティーには少し遅れました。Pylotが、有望なオープンソースツールであることに同意します。使い方は簡単で、優秀な人（Corey Goldberg）が積極的に取り組んでいます。OpenQAの創設者として、Pylotがホームページに表示され、インフラストラクチャ（フォーラム）の一部を使用していることも嬉しく思います。

ただし、私は最近、負荷テストの概念全体に欠陥があることも決定しました。アプリケーションが複雑になったHTTPトラフィックをエミュレートすることは、お尻の痛みです。それが私が商用ツールBrowserMobを作成した理由です。これは、負荷の再生時にSeleniumを使用して実際のWebブラウザーを制御する外部負荷テストサービスです。

アプローチが明らかに必要とトン通常の負荷テスト技術よりもハードウェアをしていますが、クラウドコンピューティングを使用しているときに、ハードウェアはかなり安く、実際にあります。そして、これの素晴らしい副作用は、スクリプトが通常の負荷テストよりもはるかに簡単であることです。Cookie、.NETセッション状態、Ajaxリクエストパラメータなどを抽出するために、（JMeterが必要とするような）高度な正規表現マッチングを行う必要はありません。実際のブラウザを使用しているため、ブラウザは本来の動作を実行します。

露骨に商用製品を売り込んで申し訳ありませんが、うまくいけば、このコンセプトは一部の人々にとって興味深いものであり、少なくとも、追加のハードウェアの束にアクセスできる場合に、負荷テストに対処するためのいくつかの新しい方法を考えさせるでしょう！

私はJMeterを使用しました。ウェブサーバーをテストする以外に、データベースバックエンド、メッセージングサービス、メールサーバーをテストすることもできます。

AB、包囲、宗、httperf、トランプル、Pylot、要求ログ・アナライザ、perftools

単純な使用法では、ab（apacheベンチマーク）と包囲を実行します。後でabがcookieをサポートせず、動的サイトから無限のセッションを作成するため、後で必要になります。

どちらも簡単に開始できます。

ab -c n -t 30 url

siege -b -c n -t 30s url

包囲はより多くのURLで実行できます。

最後の包囲バージョンはsiegercで詳細をオンにします。そのファイル（/usr/local/etc/siegerc）を編集することによってのみ無効にできます。

Webベースのサービスについては、loader.ioをチェックしてください。

概要：

loader.ioは無料の負荷テストサービスであり、数千の同時接続でweb-apps / apisのストレステストを行うことができます。

APIもあります。

この質問はまだ未解決なので、私も検討する必要があります。

良いニュースは、過去5年ほどの間にオープンソースツールが本当に成熟し、宇宙で普及してきたことです。

これが私の考えです：-

Jmeter vs Grinder

Jmeterは、GUIを介して構築されるXMLスタイル仕様に基づいています。

Grinderは、マルチスレッドJavaフレームワーク内でJythonスクリプトを使用しているため、プログラマー向けです。

どちらのツールもHTTPとHTTPSを処理し、使用を開始するためのプロキシレコーダーを備えています。どちらのツールも、コントローラーモデルを使用して複数のテストエージェントを実行するため、スケーラビリティは問題になりません（クラウドへのアクセスを許可）。

どちらが良いですか：-

URLの書き換え、相関、仮想ユーザーごとの一意のデータの提供、初回のシミュレーションまたはユーザーの戻り（HTTPヘッダーの操作による）などのより複雑なスクリプト要件に入ると、両方のツールで学習曲線が急になります。

とは言っても、このツールには非常に多くの読者がいて、このツールを使用するためのWeb上の例やチュートリアルがたくさんあるので、Jmeterから始めます。「ロードブロック」に来たら、Jmeterで「簡単に」行うことはできません。グラインダーを確認してください。良いニュースは、これらのツールの両方に同じJava要件があり、「ミックスアンドマッチ」ソリューションは問題外ではないということです。

追加する新機能– Selenium WebDriverの複数のインスタンスを実行するヘッドレスブラウザー。

これは、クラウドからプロビジョニングできるリソースの可用性に依存しているため、比較的新しいアプローチです。このアプローチでは、Selenium（WebDriver）スクリプトが取得され、ヘッドレスブラウザー（つまり、WebDriver = New HtmlUnitDriver（））ドライバー内で複数のスレッドで実行されます。

経験から、「ヘッドレスブラウザー」の約25のインスタンスをAmazon M1 Small Instanceから実行できます。

これが意味することは、機能テストスクリプトを転用してパフォーマンステストスクリプトにすることで、すべての相関、URL書き換えの問題が消えることです。

GrinderやJmeterなどのHTTPドライバーと比較して、負荷を駆動するためにより多くのVMが必要になるため、スケーラビリティーが損なわれます。つまり、500の仮想ユーザーをドライブする場合、20のAmazonスモールインスタンス（1時間あたり6セント）で1時間あたりわずか$ 1.20のコストで、実際のユーザーエクスペリエンスに非常に近い負荷がかかります。

また、greenletを使用する素晴らしいオープンソースのピュアpython分散スケーラブルローカストフレームワークもあります。大量の同時ユーザーをシミュレートするのに最適です。

最近、負荷テストにガトリングの使用を開始しました。負荷テストのためにこのツールを試すことを強くお勧めします。過去にSOASTAとJMETERを使ったことがあります。ガトリングを検討する主な理由は次のとおりです。

• シナリオを記録するレコーダー
• Jmeterスレッドモデルと比較してパフォーマンスが向上するAkkaとNettyの使用
• Jmeter XMLと比較して非常に保守しやすいDSL Scala
• テストを書くのは簡単で、それがscalaであっても怖がらないでください。
• 報告

ガトリングコードを使用してコードを記述する簡単な例を示します。

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

ただし、可能な限り複雑にすることができます。Gatlingで際立っている機能の1つは、非常に詳細なレポートです。

ここにいくつかのリンクがあります：
ガトリング
ガトリングチュートリアル

私は最近それについて話をしました、あなたはここで話をすることができます：https :
//docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

これは古い質問ですが、新しいソリューションについては言及する価値があります。LoadImpactのチェックアウト：http : //www.loadimpact.com。

WebLoadを試してみましたが、これはかなりきちんとしたツールです。これには、Webサイトでのユーザーの操作を記録できるテストスクリプトIDEが付属しています。また、Webサーバーでストレステストを実行するときにグラフを描画します。ぜひお試しください。

ここで述べたすべてを試してみたところ、curl-loaderが自分の目的に最適であることがわかりました 。非常に簡単なインターフェース、リアルタイムの監視、有用な統計、そこからパフォーマンスのグラフを作成します。libcurlのすべての機能が含まれています。

Blaze Meterには、セッションを記録してJMeterにエクスポートするためのクロム拡張があります（現在ログインが必要です）。また、JMeterサーバーのクラスターで実行するためにお金を払うオプションもあります（これらの価格は、私が使用を中止したLoadImpactよりもはるかに優れているようです）。

• BlazeMeter Chrome拡張機能
• それに関するブログエントリ

私は彼らと何の関係もありません。私は彼らのサービスの外観が好きですが、私はまだ有料版を使っていません。

1年ほど前にこの質問をされましたが、まだWebサイトのベンチマークの別の方法を探しているのかどうかはわかりません。ただし、この質問はまだ解決済みとしてマークされていないため、無料のWebサービスLoadImpactを提案したいと思います（ただし、提携していません）。ツイッター経由でこのリンクを取得し、この発見を共有したいと思います。それらは妥当な適切な概要を作成し、さらに数ドルで「フルインパクトモード」を取得します。これはおそらく奇妙に聞こえるかもしれませんが、あなたのサービスを押してブレーキングする幸運:)

私が見つかりましたIBMのページDetailerもで動作するように興味深いツールを。

私はopenSTAを使用しました。

これにより、Webサイトとのセッションを記録して、比較的単純なスクリプト言語で再生できます。

Webサービスを簡単にテストし、独自のスクリプトを作成できます。

これにより、スクリプトを任意の方法でテストにまとめ、反復数、各反復のユーザー数、各新規ユーザーを導入するための立ち上げ時間、および各反復間の遅延を構成できます。将来的にテストをスケジュールすることもできます。

オープンソースで無料です。

スプレッドシートに保存できる多数のレポートを作成します。次に、ピボットテーブルを使用して、結果を簡単に分析およびグラフ化します。

私たちは、言及されたMicrosoftツール-Microsoft Web Application Stress Toolを使用します。これは、私が使用した最も簡単なツールです。手動で作成されたテストでポート80のみをヒットできるなど、多くの点で制限があります。しかし、その使いやすさは実際に使用されていることを意味します。

このツールからの負荷をOpenSTAやリンクチェックスパイダーなどの他のツールで補完します。

JMeterは私の最初の評価から良さそうです。今後の継続的な統合に含めたいと思います。しかし、JMeterは複雑で、展開するのは簡単ではありません。

MSストレスツールの結果の解釈に関する別の質問を開くことをお勧めします。

Visual Studio Test Edition 2010（2008も良い）。これは、Web /負荷テストを作成するための本当に簡単で強力なツールです。

Windowsサーバーに対して使用する場合のこのツールの利点は、レポート内のすべてのperfmonサーバー統計への統合アクセスを取得できることです。本当に便利です。

その他のボーナスは、Visual Studioプロジェクトを使用して、Webサイトのコード実行をプロファイルする「パフォーマンスセッション」を統合できることです。

あなたがWindowsサーバーからウェブページを提供しているなら、これはそこにある最高のツールです。

ただし、複数のマシンを使用してアプリケーションの負荷テストを行うには、別の高価なライセンスが必要です。

負荷とパフォーマンスの測定を一流の懸念事項として扱うプロセスを開発しました。ご存知のように、プロジェクトの最後に置くと失望する傾向があります...

そのため、開発中は、セレンの使用を含む非常に基本的なマルチユーザーテストを含め、セッション管理の破損、同時実行の問題、リソースの競合の問題などの基本的な問題をチェックします。重要なプロジェクトでは、これが継続的インテグレーションプロセスに含まれるため、非常に定期的なフィードバックが得られます。

極端なパフォーマンス要件を持たないプロジェクトの場合、基本的なパフォーマンステストをテストに含めます。通常、BadBoyを使用してテストをスクリプト化し、JMeterにインポートして、ログインの詳細やその他のスレッド固有のものを置き換えます。次に、サーバーが1秒あたり100のリクエストを処理するレベルまでこれらを増やします。応答時間が1秒未満の場合、通常はそれで十分です。私たちは立ち上げ、私たちの生活とともに進みます。

極端なパフォーマンス要件のあるプロジェクトでは、BadBoyとJMeterを引き続き使用しますが、テストリグのサーバー（通常はWebサーバーとデータベースサーバー）のボトルネックを理解するために多くのエネルギーを費やしました。Microsoftイベントログを分析するための優れたツールがありますをこれは非常に役立ちます。通常、予期しないボトルネックが見つかり、可能であれば最適化します。これにより、「1台のWebサーバー、1台のデータベースサーバー」と同じくらい高速なアプリケーションが実現します。次に、通常はターゲットインフラストラクチャにデプロイし、「クラウドのJmeter」サービスの1つを使用して、大規模なテストを再実行します。

繰り返しになりますが、PALレポートはテスト中に何が起こったかを分析するのに役立ちます-運用環境では非常に異なるボトルネックがしばしば見られます。

重要なのは、ストレステストを実行するだけでなく、アプリケーションのパフォーマンスを理解するために必要な情報を収集することです。

ここで言及されている多くの優れたツールがあります。「Webアプリケーションのストレステストをどのように行いますか？」これらのツールは、実際にはWebアプリにストレスを与える方法を提供しません。これが私が知っていることです：

ストレステストでは、増え続けるユーザーへの応答を提供しているときにWebアプリがどのように失敗するかを示しています。ストレステストは、Webアプリが失敗したときの機能を示します。今日のほとんどのWebアプリ、特にソーシャル/モバイルWebアプリは、サービスの統合です。たとえば、2011年5月にFacebookが停止した場合、Pepsi.comのWebアプリにログオンできませんでした。アプリは完全に失敗したわけではなく、通常の機能の大部分だけがユーザーに利用できなくなっています。

パフォーマンステストは、アプリを同時に使用しているユーザー数に関係なく、Webアプリが応答時間を維持できることを示しています。たとえば、10人の同時ユーザーで毎秒10トランザクションを処理するアプリは、20ユーザーで毎秒20トランザクションを処理する必要があります。アプリが1秒あたり20未満のトランザクションを処理する場合、応答時間が長くなり、アプリは線形のスケーラビリティを実現できません。

また、上記の例では、1秒あたりのトランザクション数は、テストユースケース/ワークフローの成功した操作のみのものである必要があります。障害は通常、より短い期間で発生し、TPS測定が過度に楽観的になります。失敗はアプリに負荷をかけるため、ストレスとパフォーマンステストにとって重要です。

私は、http: //www.pushtotest.com/pushtotest-testmaker-6-methodologyのTestMakerユーザーガイドにPushToTest方法論を書きました。TestMakerには、オープンソース（GPL）コミュニティバージョンとTestMaker Enterprise（優れたプロフェッショナルサポートを備えた商用）という2つの種類があります。

-フランク

LoadBooster（https://www.loadbooster.com）をご覧ください。ヘッドレススクリプト対応ブラウザーPhantomJS / CasperJsを利用して、Webサイトをテストします。Phantomjsはすべてのページを解析してレンダリングし、クライアント側のスクリプトを実行します。ヘッドレスブラウザーアプローチは、複雑なAJAXの重いWeb 2.0アプリ、ブラウザーナビゲーション、マウスクリック、およびブラウザーへのキーストロークをサポートするテストシナリオを書くか、DOMに要素が存在するまで待機する方が簡単です。LoadBoosterは、セレンHTMLスクリプトもサポートしています。

免責事項：私はLoadBoosterで働いています。

jMeterよりもはるかに使いやすいZebraTesterを試してください。私はjMeterを長い間使用してきましたが、負荷テストの合計セットアップ時間は常に問題でした。ZebraTesterはオープンソースではありませんが、過去6か月間に節約した時間がそれを補います。また、ロードジェネレーターを使用してテストをすばやく実行するために使用できるSaaSポータルもあります。

もう1つ注意してください。私たちのWebアプリケーションの場合、ロックをめぐるスレッド間の競合が原因でパフォーマンスに大きな問題があることがわかりました。そのため、モラルは、ロックスキームを慎重に検討することでした。非同期のhttpハンドラーを使用して、ワーカースレッドがあまりにも多くのリクエストをスロットルすることになりました。そうしないと、アプリケーションが圧倒され、クラッシュして書き込みが発生します。それは巨大なバックログが山積みになる可能性があることを意味しましたが、少なくともサイトは稼働し続けます。

TestCompleteを見てください。

私はopenstaの提案に2番目です。SMTPを使用してテストしているサーバーを監視することができることを付け加えておきます。プロセッサーの負荷、使用されたメモリ、送信されたバイトなどを追跡します。唯一の欠点は、何か問題が見つかり、修正を実行したい場合、もはや維持されていないいくつかのオープンソースライブラリに依存しているため、コンパイルが行われることです。ソースのバージョンは、ほとんどのOSSよりもトリッキーです。

JMeterで遊んだ。テストできなかったと思う人はASP.NET Webformsでした。ビューステートがテストを壊しました。理由はわかりませんが、ビューステートを正しく処理できないツールがいくつかあります。私の現在のプロジェクトはASP.NET MVCで、JMeterはそれでうまく動作します。

私はFunkLoadで良い結果が得られました：

• ユーザー操作を簡単にスクリプト化
• レポートは明確です
• サーバーの負荷を監視できる

恥知らずな自己宣伝で非難される恐れがあるので、無料の負荷テストツールを探してこの記事にアクセスしたことを指摘しておきます。http：//www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

必要なスループットが得られなかったか、必要な柔軟性が得られませんでした。さらに、テスト後の分析で、複数の負荷テスト生成ホストの結果を簡単に集約したいと考えました。

リストにあるすべてのツールを試してみましたが、不満に思ったのは、私がやりたいことをまったく実行していないツールでした。だから私はそれを作り、それを共有しています。

ここにあります：http : //sourceforge.net/projects/loadmonger

PS：都市の俗語に精通している人々からの名前についてのコメントはありません。私はそうではなかったが、もう少し世界的になりました。

私もjMeterに投票し、@ PeterBernierの回答に引用符を追加します。

負荷テストが答える主な質問は、私のWebアプリケーションがサポートできる同時ユーザーの数です。適切な回答を得るために、 負荷テストは実際のアプリケーションの使用状況を可能な限り表す必要があります。

上記を念頭に置いてください。jMeterには、論理コントローラー、構成要素、プリプロセッサー、リスナーなど 、多くのビルディングブロックがあります。

jMeterを使用すると、現実の状況を模倣できます。たとえば、次のことができます。

1. 設定しJMeterは設定することで、実際のブラウザとして動作するように（concurrent resource download、browser cache、http headers、setting request time out、cookie management、https support、encoding、ajax support、...）
2. ユーザの要求を生成するように設定するJMeter（定義することによりnumber of users per second、ramp-up time、scheduling、...）
3. jMeterを使用して多数のクライアントを構成し、分散負荷テストを実行します。
4. テスト中にサーバーが正しく応答しているかどうかを確認するために応答を処理します。（たとえばassert、テキストを見つけるための応答）

考えてください：

• jMeterを使用すると、実際のWebアプリケーションテストを数分で簡単に開始できます。jMeterには、テストシナリオを記録する非常に簡単なツールがあります（として知られていますHTTP(S) Test Script Recorder）。
• jMeterにはhttp://jmeter-plugins.orgに多数のプラグインがあります。
• jMeter UIはSwingベースで、jMeter 3.2で優れた変更が加えられています。一方、JMeter GUIはテストとデバッグにのみ使用する必要があることを考慮してください。実際のテストのためにGUIモードで使用することはお勧めできません。https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui。シナリオを構成してテストし、非GUIモードで実行します。
• jMeter（として知られていますlisteners）には多くのレポート表示ツールがありますが、テスト中にオンにすることは想定されていません。テストを実行し、レポート（.jtlファイル）を生成する必要があります。次に、これらのツールを使用して結果を分析する必要があります。見ていてくださいhttps://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formatsまたはhttps://www.tutorialspoint.com/jmeter/jmeter_listeners.htmを。

https://www.blazemeter.com/jmeterは、あなたのテスト環境を設定する助けに非常に良いと実用的な情報を持っています。