タグ

jmeterに関するs1251のブックマーク (9)

  • JMeterの実行結果CSVデータをローカルMacにたてたElasticsearchとKibanaで可視化する | DevelopersIO

    「JMeterの結果CSV、216万行か〜。これくらいだったらJMeterの「グラフ表示」で読み込んで見られるかな〜」 CPU「ブオオオオオオオオン!」 はじめに システムの負荷試験において、Apache JMeterのようなツールを使って試験を実施・結果を出力するケースもあると思います。結果ファイルのサイズがそれほど大きくない場合は、全データを計算する(JMeterでいう「統計レポート」)で問題ありませんが、例えば、長時間負荷をかけたので時系列でデータをグラフ化したい、といったことになると事情が変わってきます。JMeterの結果CSVは手元にあるので、なんとかこれを活用したいところではありますが、数百万行レベルのデータになると、とたんにExcelなどでは辛くなります(というか最大行数的に無理な気がします)。 そこで、ちょうど、弊社木戸がElasticsearchシリーズを連載しているとこ

    JMeterの実行結果CSVデータをローカルMacにたてたElasticsearchとKibanaで可視化する | DevelopersIO
  • JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった | mah365

    JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった。知らなかった(迫真)。 典型的なRailsアプリのテストプラン そういう訳で典型的なRailsアプリのテストプランを書いてみたのがこちら。 ユーザーログインページでCSRFトークンを取得し、常にHTTPヘッダにつけるようにする ユーザーログイン情報をクッキーに保存 といった典型的な処理を盛り込んでいます。あとはREADME.mdを読んでもらえれば大体の書き方が把握できるかと思います。 ちなみに、# Debugというコメントの下2行をコメントアウトしてもらうと、JMeter上でデバッグ用の出力を表示することができます。テストプランが上手く動かないときに、リクエストヘッダやレスポンスを確認するのに便利です。 で、これをコマンドラインで ruby sample.jmx.rb && j

    JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった | mah365
  • もしかすると自分以外の人にはあんまり参考にならないかもしれないJMeterのTips - Qiita

    負荷テストツールJMeterのTipsです。 最近はgatlingとかiagoあたりが流行ってますが、情報の入手のしやすさや、豊富なプラグインによる機能面での優位性からJMeterはまだまだ使われるのではないかなぁと思っています。 ということで、自分が何度か負荷テストを行った際に学んだJMeterのTipsをまとめたいと思います。 タイトルの通り、かなり独自路線で学んだ点が多いのであんまり参考にならないかもです。 なお、ある程度は使い方を知っている方を対象にしています。 ある程度というのは、HTTPサンプラーをベースとしたスクリプトをTest Script Recorder(旧HTTP Proxy Server)を使って流した処理を元に作ったことがあって、CSV等から読んだりしたユーザごと等の可変パラメータを使ってひと通りのテストをしたことがあったりする程度です。 スクリプトはGUIで作っ

    もしかすると自分以外の人にはあんまり参考にならないかもしれないJMeterのTips - Qiita
  • 無料パフォーマンステスト | 負荷テスト

    これまで、負荷テストの実行には専門知識と実行環境の準備に多くのコストが必要でした。社会からWebサービスの性能に関する不具合をゼロにするために、簡単、無料、圧倒的な負荷テストサービスを提供します。 ユーザビリティ サーバの応答速度は常に変化し、利用者の直帰率に大きく影響を与えます。サーバの応答速度を可視化し、日々計測することで、すみやかに問題個所を発見できます。 性能測定 サーバの性能不足により、せっかくの営業機会を失うサイトが多く存在します。サーバの性能を正しく把握することで、予測される負荷に応じたサーバの増強ができます。 負荷チェッカー/カレンダーを利用したテスト(ジョブ)の予約や、グラフィカルな結果画面を準備しており、初心者の方にも大変使いやすいサービス。インスタントテスト/URLを入力するだけで、すぐに負荷テストを行うことができます。シナリオテスト/ログインが必要なページや複数のペ

    無料パフォーマンステスト | 負荷テスト
  • ruby-jmeter - so what

    JMeterはとても強力なツールなんですが、UIがいまいち(ですよね?)なのとテストケースがXMLなので、あまり積極的に使っていませんでした。 しかし、どうしてもJMeterを使わざるを得ないケースが出てきて*1、GUIツールとXMLを避ける方法をいろいろと探していたところ、ruby-jmeterがというライブラリが見つかりました。 ruby-jmeter https://github.com/flood-io/ruby-jmeter Tired of using the JMeter GUI or looking at hairy XML files? はい、疲れました…というひとのためにRubyのDSLでjmxを出力 or JMeterを実行してくれます。 require 'ruby-jmeter' test do thread_group count: 3, duration: 60

    ruby-jmeter - so what
  • Python 製の負荷試験ツール Locust を試してみた - co3k.org

    Web の負荷試験ツールとして代表的なのは Apache JMeter だと思いますが、 Apache JMeter 自体が結構重いのと、テストシナリオの保守が GUI ツールでは結構ツライ (シナリオファイルは XML ですが、とても人間が手を加えられるような代物じゃない) なあということで代替となるものを探していました。 で、心惹かれたのが以下のツールです。 Gatling Tsung Locust Gatling は非常によさそうなんですが、うーん要 JDK か……あとは複数台から負荷を掛けることができないというのもちょっとマイナスですね。まあどっちもどうにかしようと思えばどうにかなるポイントではあるんですけど。 Tsung は Erlang 製で、仕事で Erlang 使う可能性も出てくる気がするのでこれで慣れ親しんでおくのもいいかなーと思ってシナリオファイルを覗いてみたら ド直球

  • JMeterの使い道 - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    JMeterの使い道 - プログラマの思索
  • スケール可能なTwitterの負荷テストの仕組み [GTAC 2013] - ワザノバ | wazanova.jp

    [Video] http://www.youtube.com/watch?v=99RABfKNfcY [Slide] http://goo.gl/9VY2b TwitterのJames Waldropが、オープンソースのロードジェネレータライブラリlagoと、スケールが可能な負荷テストの仕組みについてGTAC (Google Test Automation Conference) 2013で語ってます。Twitterには番トラフィックの一部を利用したテストもありますが、講演ではテスト環境でのロードジェネレータを話題にしてます。 FacebookからTwitter転職し、lagoをつくった理由は、 ありあわせのツールをもってきて使ってもだめで、エンジニアであれば何か開発しないと他のエンジニアから尊敬されない。 Scalaで書いてみたかった。 既存のロードジェネレータはどれも役に立たない

  • chef + fabricを用いたクラウドサービス管理 | SmartNews開発者ブログ

    ゴクロの大平と申します。はじめまして。 4月からjoinさせていただいた、特に特記事項の無い平凡なプログラマです。さだまさしが好きです。 SmartNews開発者ブログをご覧になる方々は、サービスの裏側で動作するクローラーや多種多様な機械学習のロジックであったり、フロントエンドUIの話であったり、サービス固有の話に興味が有る方が多いと存じますが、都合上(原稿の担当順番の都合上)、今回は一般的な話をさせていただきます。 ※先掲の話題については次回以降取り上げられますので、お楽しみに。 一般的な話題とはいえ、大企業とスタートアップでは取り巻く環境や解決すべき課題も異なっていますので、その辺もあわせてお伝え出来ればなと思います。 なお、今回のテーマは、サーバー/ミドルウェアの構成管理ツールとして最近有名になってきた「chef」と「fabric」です。 かなり長文のエントリーになってしまい

  • 1