Articles

Siegeでアプリをロードテスト

July2019

タグ:rails_performance•rails•programming
読み取り時間:8分
  • 一意のUrlをテキストファイルにダンプ
  • 攻城テスト
  • その他のリソース

前回、アクセスするために認証を必要とするページでapache benchmarkを使用してパフォーマンステストを行いました。

今日は、siegeを使用してページ上の多くの一意のUrlを訪問し、そのプロセスのベンチマークを取得する方法を理解します。 次に、Datadogでのパフォーマンスプロファイリングを理解し、これら三つのツールをまとめて、アプリケーションに意味のある改善を行う準備ができているはず

この一連の投稿は、Nate BerkopecのThe Complete Guide to Rails Performanceの直接の結果であり、彼のスクリーンキャストとSteve GrossiのApache Bench、Siege、JMeterを使用したRailsアプリのロードテストの助けを借り これらのリソースで武装し、巨人の肩の上に立って、オフに私たちは行く。

:

Siegeは、http負荷テストおよびベンチマークユーティリティです。 これは、web開発者が強迫の下で自分のコードを測定し、インターネットにロードするために立ち上がる方法を確認できるように設計されました。 Siegeは、基本認証、cookie、HTTP、HTTPS、FTPプロトコルをサポートしています。 これは、そのユーザーがシミュレートされたクライアントの構成可能な数でサーバーをヒッ これらのクライアントは、サーバーを”包囲下に置きます。”

あなたはbrew install siegeで包囲を得ることができます。

私はあなたがそれを与えるUrlのリストを実行することができるのでそれを使用しています。 あなたのアプリがストアであり、数千の製品がリストされているとします。 各製品には、、またはのような一意のURLが必要です。 そのproduct-guidは、同じ製品名を持つ2つのアイテムがある場合でも、一意のUrlを持つことができることを確認します。

データベースに何があるかを知ると、product-guidproduct-nameを簡単に連結し、の最後に貼り付け、アプリケーション内の百、千、一万の一意の製品Urlのリストを思い付くこ これらをテキストファイルに保存して、できるだけ早くそれらのページのすべてをSiegeに訪問させた場合…これは何らかの良いストレステストのように見えるかもしれませんか?

一意のUrlをテキストファイルにダンプする#

おそらくrails consoleセッションで作業を開始し、URLスキームにどのようにアクセスするかを理解します。

私はコンソールを起動し、入力しました:

私は多くのデータを持つアカウントを見つけるために私たちの開発データベースを調べました。4887idを持つアカウ

campaign.to_paramは、キャンペーンからUrlを構築する方法です。guidtitle文字列と連結し、その上で.parameterizeを呼び出します。 この一連のキャンペーンでは、自動化されたQAテストスイートによってプログラムで生成されます。

終了すると、次のようなものが表示されることがありますall_campaign_urls.txt:

Siege test#

でこれらのすべてのページにアクセスすると、siege --helpでき、ファイルを渡すためのフラグを見ることができます:

すでに私たちは--file--headerを必要としていることを知っていますが、いくつかのcookieを送信して認証されたセッションを偽造する必要があるため、前回

--get:

HTTPヘッダーを取得し、プルダウンしてトランザクションを表示します。 アプリケーションのデバッグに最適です。

だから、私たちのQAアカウントとしてログインしてみましょう。 私はこれをすべてローカルで実行しているので、私は私たちのDBで関連する電子メールアドレスを見つけることができます。 もちろん、パスワードはわかりませんが、ローカルパスワードのリセットを強制し、Mailcatcherで電子メールを取得し、必要なパスワードに設定することができます。

これらのヘッダーを取得しましょう。

cookieを使用してcURLテスト要求を行うことができます。 私がするとき

$ curl -v http://localhost:3000/account/campaigns/dd4dfb48aa-dec-05-drive-by-test

/users/sign_in

へのリダイレクトではなく、ページが戻ってくることを期待しています認証に失敗したと思われるものは次のようになります。

cookie:

_ts_session_id: c86fd1fe38d7a6c56ce1ef5990045057fd827a2c5655094bcce3748d6ee6d3e4: ImRhMDY1YjdjYjMwNGNjNWUxNzFkNDhjOGQ0YzA0OTIwIg%3D%3D--98c228cb35af1a269ee894c22540b81848e2ed09

そして、私たちはビジネスにいます:

200のステータスコードに注目してください。 私はtail -f log/development.logすることができ、送信されたcookieが認証されたユーザーに関連付けられていることを示すすべての活動を見ることができます。

私が最初に気づくのは、これらが非常に長いページの読み込み時間のように思えることです。

私は約162の異なるUrlをロード包囲を持っています。 デフォルト構成でsiegeを実行すると、同時に20人のユーザーが実行されます。 これは私のlocalhostが扱うことができるもののために少し多くのように見えたので、私は最初に2人のユーザーに同時ユーザーの数を落としてから1人にしました。

同時ユーザー数を設定するには、--concurrent=NUMフラグを追加するだけです。 私はまだ出力が殺到していたので、同時ユーザーを1に落とし、ロードするページのリストから20ページを除くすべてを削除しました。 私はそれに60秒のtimeフラグを与えました: -t 60s

すべてが言われて完了すると、siegeが時限的なGETリクエストをたくさん作っているのがわかります:

最終的には、すべてが解決され、ロードテストの概要が表示されます:

ええ、OK、これはクールです、ジョシュ、しかし、どのように私はこれで役に立つ何かをすることになっていますか?

素晴らしい質問! 我々のアプリは、現実の世界で出て、その時間のほとんどを費やしている場所を確認するために、その時間。 ローカルでより多くのベンチマークを行うことができますが、本番環境で実際のアプリと対話する実際の人々から収集された実世界のデータは、最も有用なデー

したがって、私はすぐに書くことになります私はDataDogにRailsアプリから有用なデータを取得する方法について書かれています!

コメントを残す

メールアドレスが公開されることはありません。