手軽に負荷テストができるツール「Taurus」がスゴい
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
Gatlingによる分散負荷試験を自動化するKubernetesオペレーターGatling Operatorの紹介 - ZOZO TECH BLOG
こんにちは。SRE部の川崎（@yokawasa）、巣立（@tmrekk_）です。私たちは、ZOZOTOWNのサイト信頼性を高めるべく日々さまざまな施策に取り組んでおり、その中の1つに負荷試験やその効率化・自動化があります。本記事では、私たちが負荷試験で抱えていた課題解決のために開発、公開したOSSツール、Gatling Operatorを紹介します。 github.com はじめに ZOZOTOWNは非常にピーク性のあるECシステムであることから、常にそのシステムが受けうる負荷の最大値を意識しております。想定しうる最大規模の負荷を受けてもユーザー体験を損なうことなくサービス継続できることをプロダクションリリースの必須条件としています。したがって、新規リリースやアップデート、大規模セールなどのシステム負荷に影響を与えうるイベント前など、比較的頻繁に負荷試験を実施しています。そして、社内でもっ
毎秒1万リクエストの負荷試験をした話 - pixiv inside
はじめまして。ピクシブで広告関連のプロダクトを開発しているeastです。今回は、社内で運用している広告配信サーバーの負荷テストを実施したので、その話をしたいと思います。 経緯 ピクシブの広告配信サーバーは、pixiv本体を中心に複数のサービスに対して広告配信を行なっています。現在私はこの広告配信サーバーの大規模改修を行なっているのですが、先日ついに広告配信サーバーの改修がほぼ完了したので、試しに負荷試験を行なってみたいと思い立ちました。 目標は毎秒1万リクエスト ピクシブの広告配信サーバーへのリクエスト数はDailyで 4〜6億req もあり、これは毎秒平均に直すと約 5,000RPS(Request Per Second) になります。さらに、ピークタイムである休日の深夜帯には 12,000RPS にも達します。つまり新しい広告配信サーバーにも、毎秒12,000のリクエストを捌く性能が必
どれだけリクエストをさばけるのかを待ち行列理論で考えてみた - Qiita
テレビで素敵なサイトが紹介されていたのでアクセスしてみたら、なかなかレスポンスが返ってこなかったりステータスコード503になったりすることってありますよね。 テレビで紹介されたことで多くの人がサイトにアクセスした結果、そのサービスのキャパシティを超えてしまったわけです。 どうなるとキャパシティを超えるのでしょうか？ また、いつからレスポンスが遅くなるのでしょう。 効果的にリクエストをさばくにはどうしたらいいのでしょう。 Photo by Roman Arkhipov on Unsplash 待ち行列理論を使って理想的なモデルからこれらを考えてみたいと思います。 待ち行列理論はコンピュータサイエンスをやってきた人はみんな触れたことがあるとは思いますが、大石の場合はそれが何十年も(!)前のことなのであらためて思い出してみました。 モデル Railsでサービスを提供するとき、rackサーバとして
7. 負荷テストの評価基準には何を使えばよいのか? | Oracle 日本
～テストツールを使う際の負荷量の指標～ 6. システムがパフォーマンスを維持するためのメモリ管理について に戻る はじめに 性能テスト、負荷テストを行う上では、達成すべき目標値の定義が必要となります。しかし、性能テストでは様々な指標が存在しており、どの指標をもって目標とし、結果を判定すべきか判断が難しい場合があるでしょう。 実際に、Webシステムの性能評価を行うための指標には以下があります： * 同時接続ユーザー数(Number of Virtual Users) * 時間あたりのユーザーシナリオ実行本数(Transactions per hour) * 時間あたりのページ処理数(Received pages per hour) * 時間あたりのヒット数（Hits per hour） * サーバー平均応答時間(Average Server times, etc.) * サーバー側のCPU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Estimating Load on Application Server Instances (Sun GlassFish Enterprise Server 2.1 Deployment Planning Guide)
Determining Concurrent Users in Your Load Tests