web-applications - Web アプリケーションでストレステストを実行していますか?

Question

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

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

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

これらのツールによって生成されたレポートは、私にはあまり意味がなく、サイトがサポートできる同時負荷の種類を把握するために何時間も費やしました。最もばかげたバグやボトルネックが常に発生するため (たとえば、Web サーバーの構成ミスなど)、常に価値がありました。

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

score 113 · Accepted Answer

JMeterに別の投票があります。

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

ただし、複雑なテストを開始すると、学習曲線が急になりますが、それだけの価値があります。非常に迅速に起動して実行できます。実行するストレステストの種類によっては、それで問題ない場合もあります。

長所：

Apache プロジェクトのオープンソース/無料ツール (購入に役立ちます)
簡単に始められ、核となる概念を理解すれば簡単に使用できます。(つまり、リクエストの作成方法、アサーションの作成方法、変数の操作方法など)。
非常にスケーラブルです。私は 11 台のマシンでサーバーに 1 時間あたりほぼ 100 万ヒットの負荷を生成するテストを実行しました。思っていたよりもずっと簡単にセットアップできました。
アクティブなコミュニティと、使い始めるのに役立つ優れたリソースがあります。最初にチュートリアルを読んで、しばらく遊んでください。

短所：

UIはSwingで書かれています。(うーん！)
JMeter は、サーバーから返された応答テキストを解析することによって機能します。したがって、あらゆる種類の JavaScript の動作を検証しようとしている場合は、運が悪いです。
プログラマー以外の学習曲線は急勾配です。正規表現に精通している場合は、すでにゲームの先を行っています。
サポートフォーラムには、ドキュメントをざっと見ただけでも簡単に解決できる愚かな質問をする(罵倒を挿入する) バカが多数います。(「JMeter を使用して Windows GUI のストレステストを行う方法」が頻繁に表示されます)。
「すぐに使える」レポートは、特に大規模なテストの場合、多くのことが望まれます。上記のテストでは、'xml-logfile' から 'html' への変換の一部を実行する簡単なコンソールアプリを作成する必要がありました。ただし、これは数年前のことなので、今後は必要なくなる可能性があります。

score 37 · Accepted Answer

グラインダーを使用しました。これはオープンソースであり、非常に使いやすく、非常に構成可能です。Java ベースで、スクリプトに Jython を使用します。.NET Web アプリケーションに対して実行したので、これが Java 専用のツールだとは思わないでください (その性質上、Web ストレスツールは使用するプラットフォームに結び付けられるべきではありません)。

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

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

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

score 24 · Accepted Answer

このパーティーには少し遅れました。私は、Pylotが最高の新進気鋭のオープンソースツールであることに同意します。使い方は簡単で、偉大な人物 ( Corey Goldberg )が積極的に取り組んでいます。OpenQAの創設者として、Pylot が現在私たちのホームページに掲載されており、私たちのインフラストラクチャ (つまり、フォーラム) の一部を使用していることも嬉しく思います。

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

このアプローチには明らかに、通常の負荷テスト手法よりも大量のハードウェアが必要ですが、クラウドコンピューティングを使用している場合、ハードウェアは実際にはかなり安価です。これの良い副作用は、スクリプト作成が通常の負荷テストよりもはるかに簡単になることです。Cookie、.NET セッション状態、Ajax 要求パラメーターなどを抽出するために、高度な正規表現マッチング (JMeter が必要とするような) を行う必要はありません。実際のブラウザーを使用しているので、本来のことを行うだけです。

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

score 16 · Accepted Answer

JMeterを使用しました。Webサーバーのテストに加えて、データベースバックエンド、メッセージングサービス、および電子メールサーバーをテストすることもできます。

score 13 · Accepted Answer

13

ab、siege、tsung、httperf、Trample、Pylot、request-log-analyzer、perftools

于 2011-04-19T05:05:46.463 に答える

score 10 · Accepted Answer

Webベースのサービスについては、loader.ioを確認してください。

概要：

loader.ioは無料の負荷テストサービスであり、何千もの同時接続を使用してWebアプリ/APIのストレステストを行うことができます。

APIもあります。

score 9 · Accepted Answer

単純な使用法として、ab(apache ベンチマーク) と siege を使用します。ab は Cookie をサポートしておらず、動的サイトから無限のセッションを作成するため、後者が必要です。

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

ab -c n -t 30 url

siege -b -c n -t 30s url

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

前回の siege バージョンでは、siegerc で冗長性がオンになっていましたが、これは面倒です。そのファイルを編集することによってのみ無効にすることができます（/usr/local/etc/siegerc）。

score 9 · Accepted Answer

この質問はまだ未解決なので、私も検討したほうがよいでしょう。

良いニュースは、過去 5 年ほどの間にオープンソースツールが本当に成熟し、この分野で人気を博したことです。悪いニュースは、非常に多くのツールが世の中に出回っていることです。

ここに私の考えがあります： -

Jmeter vs グラインダー

Jmeter は、GUI を介して構築される XML スタイル仕様から駆動されます。

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

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

どちらが良いですか： -

URL の書き換え、関連付け、仮想ユーザーごとの一意のデータの提供、初回のシミュレートまたはユーザーの復帰 (HTTP ヘッダーの操作による) など、より複雑なスクリプト要件が必要になるため、両方のツールの学習曲線は急勾配です。

とはいえ、このツールには多くの支持者がいて、このツールを使用するための多くの例とチュートリアルがウェブ上にあるため、Jmeter から始めます。「障害」に遭遇した場合、それは Jmeter では「簡単に」できないことであり、Grinder を見てください。幸いなことに、これらのツールはどちらも Java 要件が同じであり、「組み合わせて使用する」ソリューションも問題外ではありません。

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

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

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

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

Grinder や Jmeter などの HTTP ドライバーと比較して、負荷を駆動するために必要な VM が増えるため、スケーラビリティが損なわれます。とはいえ、500 人の仮想ユーザーを動員しようとしている場合、20 の Amazon Small Instances (それぞれ 1 時間あたり 6 セント) を使用すると、1 時間あたりわずか 1.20 ドルのコストで、実際のユーザーエクスペリエンスに非常に近い負荷が得られます。

score 8 · Accepted Answer

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

シナリオを記録するレコーダー
Akka と Netty を使用すると、Jmeter スレッドモデルと比較してパフォーマンスが向上します
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 つは、非常に詳細なレポートです。

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

私は最近それについて講演しました。こちらで講演をご覧いただけます:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -ガトリング.pdf

score 8 · Accepted Answer

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

score 6 · Accepted Answer

これは古い質問ですが、新しいソリューションは言及する価値があると思います。LoadImpact を確認してください: http://www.loadimpact.com。

score 4 · Accepted Answer

WebLoadを試してみましたが、これは非常に優れたツールです。Web サイトでのユーザーアクションを記録できるテストスクリプト IDE が付属しています。また、Web サーバーでストレステストを実行すると、グラフが描画されます。試してみてください、強くお勧めします。

score 3 · Accepted Answer

Blaze meter には、セッションを記録して JMeter にエクスポートするための Chrome 拡張機能があります (現在はログインが必要です)。また、JMeter サーバーのクラスターで実行するためにお金を支払うオプションもあります (価格は、使用をやめたばかりの LoadImpact よりもはるかに優れているようです)。

有料版はまだ使っていませんが、サービスの見た目が好きです。

score 3 · Accepted Answer

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

score 1 · Accepted Answer

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

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

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

Windows サーバーから Web ページを提供している場合、これが最適なツールです。

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

score 1 · Accepted Answer

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

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

JMeter は私の最初の評価では良さそうです。今後の継続的インテグレーションに含めたいと思っています。しかし、JMeter は複雑で、ロールアウトするのは簡単ではありません。

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

score 1 · Accepted Answer

1

IBM Page Detailerも興味深いツールであることがわかりました。

于 2008-08-28T19:38:25.400 に答える

score 1 · Accepted Answer

openSTAを使用しました。

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

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

これにより、任意の方法でスクリプトをテストにまとめて、反復回数、各反復のユーザー数、各新規ユーザーを紹介するためのランプアップ時間、および各反復間の遅延を構成できます。テストは将来的にスケジュールすることもできます。

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

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

score 1 · Accepted Answer

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

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

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

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

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

-フランク

score 1 · Accepted Answer

私たちは、負荷とパフォーマンスの測定を第一級の関心事として扱うプロセスを開発しました - あなたが言うように、それをプロジェクトの最後まで放置すると、失望につながる傾向があります...

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

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

極端なパフォーマンス要件を持つプロジェクトでは、BadBoy と JMeter を引き続き使用しますが、テスト装置のサーバー (通常は Web サーバーとデータベースサーバー) のボトルネックを理解することに多くのエネルギーを注ぎます。これに大いに役立つMicrosoft イベントログを分析するための優れたツールがあります。通常、予想外のボトルネックが見つかりますが、可能であれば最適化します。これにより、「1 つの Web サーバー、1 つのデータベースサーバー」上で可能な限り高速なアプリケーションが得られます。その後、通常はターゲットインフラストラクチャにデプロイし、「Jmeter in the cloud」サービスの 1 つを使用してテストを大規模に再実行します。

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

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

LoadBooster ( https://www.loadbooster.com ) をご覧ください。ヘッドレススクリプト可能ブラウザ PhantomJS/CasperJs を利用して Web サイトをテストします。Phantomjs はすべてのページを解析してレンダリングし、クライアント側のスクリプトを実行します。ヘッドレスブラウザーアプローチは、複雑な AJAX 負荷の高い Web 2.0 アプリ、ブラウザーナビゲーション、ブラウザーへのマウスクリックとキーストロークをサポートするテストシナリオを作成するか、DOM に要素が存在するまで待機するテストシナリオを簡単に作成できます。LoadBooster は Selenium HTML スクリプトもサポートしています。

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

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

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

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

PS：都会のスラングに精通している人々からの名前についての卑劣なコメントはありません。私はそうではありませんでしたが、今はもう少し世俗的です。

score 0 · Accepted Answer

FunkLoadで良い結果が得られました:

ユーザー操作のスクリプト化が容易
レポートは明確です
サーバーの負荷を監視できます

score 0 · Accepted Answer

もう 1 つ注意してください。私たちの Web アプリケーションでは、ロックをめぐるスレッド間の競合が原因でパフォーマンスに大きな問題があることがわかりました。最終的には、ワーカースレッドが非同期 http ハンドラを使用してあまりにも多くのリクエストを調整するようになりました。そうしないと、アプリケーションが圧倒されてクラッシュし、燃え尽きてしまいます。これは、膨大なバックログが山積みになる可能性があることを意味しましたが、少なくともサイトは稼働し続けます.

score 0 · Accepted Answer

0

TestCompleteを見てください。

于 2008-08-21T10:34:39.620 に答える

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

ロードテストで答えられる主な質問は、Web アプリケーションで同時にサポートできるユーザー数はどれくらいかということです。適切な回答を得るには、 負荷テストで実際のアプリケーションの使用状況を可能な限り再現する必要があります。

上記の点に注意してください。jMeterには、これに役立つ多くのビルディングブロックLogical Controllers、Config Elements、Pre Processors、Listeners があります。

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

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

考えてください：

jMeter を使用して、実際の Web アプリケーションのテストを数分で簡単に開始できます。jMeter には、テストシナリオを記録する非常に簡単なツールがあります ( として知られていますHTTP(S) Test Script Recorder)。
jMeter にはhttp://jmeter-plugins.orgにたくさんのプラグインがあります。
jMeter UI はスイングベースであり、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には、テスト環境の構成に役立つ非常に優れた実用的な情報があります。

web-applications - Web アプリケーションでストレス テストを実行していますか?

30 に答える 30

Related

Reference

web-applications - Web アプリケーションでストレステストを実行していますか?