株式会社マーベラスさん主催の勉強会まべ☆てっく vol.2にて登壇させて頂きました。 負荷試験をかける前に目を通しておいていただきたい資料となります。 https://marv-tech.connpass.com/event/42023/
負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観
負荷ツールとしてGatlingのことを少し前から耳にする機会が増えたので、利用してみることにした。 色々既出だとは思うが、公式のQuickstartに従って試してみたのでメモ。 GUIが必要だったので、今回は手元のMacで実行。 Gatlingとは Java/Scala製の負荷テストツール。 JMaterと似た感じのツールではあるが、 ハイパフォーマンス 見やすいレポートHTML developerフレンドリーなシナリオファイル というのをウリとして謳っている。 たぶん、3項目とも対JMater(重い・レポート見づらい・XMLのシナリオつらい)を意識したメリットだろうなー。 なお、シナリオファイルは。。。 Gatling simulation scripts are written in Scala, but don’t panic! わろた。 というわけで、触ってみる Install J
JJUG CCC 2015 Spring セッション資料 企業システムを始めとしたエンタープライズ向けと位置づけられるJava EEですが、本質は大規模で信頼性の高いサーバーアプリケーションを開発するためのプラットフォームです。 いわゆるSNSやソーシャルゲームなどコンシューマー向けのサービスのアーキテクチャも大規模化・複雑化している中、Java EEが提供する機能は非常に魅力的です。 このセッションではコンシューマー向けのサービスなどで培われた JPAを用いた開発におけるデータベースのスケールアウト戦略 JUnitとJMeterクラスタで行うゲームサーバーの大規模負荷テストの自動化 など実践的なJava EE開発のケーススタディをご紹介します。Read less
はじめに JMeter のテスト結果を Grafana とかで見れたら幸せになれそうだなーって思っていたら Backend Listener を使えばレスポンスタイムを InfluxDB と Grafana で可視化出来るよーって @muramasa64 さんに教えて貰ったので早速試してみた。 このグラフでも悪くはないんだけど...。 参考 Apache JMeter - User's Manual: Live Statistics 手順 準備 JMeter 2.13 をダウンロードしてインストール(今回は MacOS X にて試す) 負荷を掛ける対象のアプリケーション(PlayFramework)が動いている Docker コンテナを用意 InfluxDB と Grafana が動く Docker コンテナを用意 Docker コンテナの構成 % docker ps CONTAINER
前回、「負荷テストあれこれ-Microsoft Web Application Stress Tool- 」で、簡易的に行える負荷ツールについて書きましたが、もう少し複雑なシナリオで負荷テストができるJMeterというツールについても書いてみたいと思います。 JMeterは、MS Web Application Stress Toolに比べ負荷ツールとしては多機能ですがその分、使い方はMS Web Application Stress Toolより複雑になっています。 負荷テストの対象や用途に応じて使いわけを行った方がスムーズに行えると思います。 ・ Webアプリ以外のテストにも利用可能 FTPやSOAP、LDAP、JDBCリクエストのテストも可能。 参考: JmeterでDB負荷テストをやってみよう! ・ SSL通信下でもテスト可 JDK1.4以上の環境であればそのまま利用できますが、そ
こんにちは、インフラストラクチャ本部の@nagaseyasuhitoです。このエントリは GREE Advent Calendar 2014 10日目の記事です。昨日はイケメンmoritaさんによる男性エンジニアリングマネージャが長期育休を取った話でした。 エンジニアブログのアカウントは2年くらい前からあるのですが、これが初エントリになります。グリーでは比較的珍しいJavaEEを始めとしたサーバーサイドJavaアプリケーションの開発、SolrやHadoopといったミドルウェアの周辺機能開発や運用などを行っています。どうぞよろしくお願いします。 最近はPvE/PvP/GvGなどユーザー同士がリアルタイムに協調プレイする際、クライアント-サーバー間を常時接続通信で行うゲームが増加しています。このような場合はHTTPのREST APIなど慣れ親しんだプロトコルでは要件を満たしきれないため、Web
JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった。知らなかった(迫真)。 典型的なRailsアプリのテストプラン そういう訳で典型的なRailsアプリのテストプランを書いてみたのがこちら。 ユーザーログインページでCSRFトークンを取得し、常にHTTPヘッダにつけるようにする ユーザーログイン情報をクッキーに保存 といった典型的な処理を盛り込んでいます。あとはREADME.mdを読んでもらえれば大体の書き方が把握できるかと思います。 ちなみに、# Debugというコメントの下2行をコメントアウトしてもらうと、JMeter上でデバッグ用の出力を表示することができます。テストプランが上手く動かないときに、リクエストヘッダやレスポンスを確認するのに便利です。 で、これをコマンドラインで ruby sample.jmx.rb && j
負荷テストツールJMeterのTipsです。 最近はgatlingとかiagoあたりが流行ってますが、情報の入手のしやすさや、豊富なプラグインによる機能面での優位性からJMeterはまだまだ使われるのではないかなぁと思っています。 ということで、自分が何度か負荷テストを行った際に学んだJMeterのTipsをまとめたいと思います。 タイトルの通り、かなり独自路線で学んだ点が多いのであんまり参考にならないかもです。 なお、ある程度は使い方を知っている方を対象にしています。 ある程度というのは、HTTPサンプラーをベースとしたスクリプトをTest Script Recorder(旧HTTP Proxy Server)を使って流した処理を元に作ったことがあって、CSV等から読んだりしたユーザごと等の可変パラメータを使ってひと通りのテストをしたことがあったりする程度です。 スクリプトはGUIで作っ
WEB+DB PRESS の Vol.83 で、負荷テストの記事を書いたので是非読んで頂きたい。 2014/10/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.83@Gihyo Digital Publishing今回の記事における対象読者について#JMeter だ、JMeter を撃滅せよ。 負荷テストスクリプト書くのに GUI なんぞいらないのですよ。 素人騙すんなら、それでいいかも知らんけども、そういう事じゃないでしょう。 GUI なしでも書けますよって、そのヤヴァイ XML を俺に見せるな。 負荷かけてる最中にサーバより先に死んだりするような負荷テストツールを後生大事に使うのをやめて欲しいのです。 今回は、新進気鋭のツールであるところのGatlingを紹介し
更新履歴 2014/2/17 コメント頂いた内容を反映、誤字を修正 なぜELBの負荷テストはJMeterクライアント(GUI)1台からではだめか。 当初、ELB配下に、AZ-Aに2台、AZ-Cに2台の合計4インスタンスがある構成で、自分の開発マシンでJMeter(GUI)を動かして負荷テストをしていたのですが、なぜか、AZ-Aの2台にしか負荷が入っていない。 ググっていたら、AWS Japanの公式スライドを発見 http://www.slideshare.net/AmazonWebServicesJapan/20130612-aws-meisterregenerateelbpublic ↑のp49に、 「都度DNS解決を行うツールが望ましい」 とあります。 なるほど確かに、JMeterはDNSキャッシュしてしまっているようです。↓ https://twitter.com/just_do_
このエントリは、PostgreSQL Advent Calendar 2013のDay3の記事です。 「データベースの負荷試験」を考える時、皆さんはどのような方法で実施することを検討するでしょうか。自前のテストスクリプトでしょうか。あるいは、データベース単体の負荷試験は行わず、Webシステム全体の負荷試験として実施するでしょうか。 PostgreSQLには、pgbenchというベンチマークツールが付属しており、このツールのシナリオを作成することで多少は独自のシナリオでの試験を行うことも可能ですが、状況によってはそれだけでは自由度が不足することがあります。 今回は、Webシステムの負荷テストでよく使われるJMeterを使って、自由なシナリオでPostgreSQL単体の負荷試験を行う方法を紹介します。 (なお、JMeterは非常に多機能な負荷生成ツールですので、今回はJMeterの網羅的な説明
よく訓練されたアップル信者、都元です。12月ですね! 全国のエンジニアの皆様! いよいよこの季節がやってまいりました。そう、アドベントカレンダーです。 今年のDevelopers.IOでは、複数テーマのアドベントカレンダーが同時進行していくようですが、これは「クラスメソッドAWSチーム」によるアドベントカレンダーです。これからクリスマス・イブまでの毎日、1つずつエントリーを投下していきます。 CloudFormationビッグバンテンプレート クラスメソッドAWSチームのアドベントカレンダー2013は、題して「CloudFormationビッグバンテンプレート」です。 AWS公式ページの中にAWS CloudFormation サンプルテンプレートというページがあります。多くのテンプレートはその名の通り「サンプル」なのですが、中にはWordpressやRedmineサーバを構築するテンプレ
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Connector/Jを http://www.mysql.com/downloads/connector/j/ からダウンロードして、解凍した中に入ってる mysql-connector-java-x.x.x-bin.jar を、JMeterのlibフォルダの中にいれておく。 JMeterを起動して、 適当なスレッドグループに ・設定エレメント→JDBC Connection Configuration ・サンプラー→JDBC Request を追加 JDBC Connection Configurationでは、とりあえず -- Database URL: jdbc:mysql://localhost:3306/test JDBC Driver Class: com.mysql.jdbc.Driver Username: root Password: --
[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で書いてみたかった。 既存のロードジェネレータはどれも役に立たない
こんにちは、今回から何回かに分けて Apache JMeter の使い方について記事を書いてみたいと思います。 単純に負荷を限界までかけるだけのテストを行う場合、AB(Apache Bench) 等の簡易なツールから行う方法から、JMeter のように GUI のツールを備えたシナリオテストまで可能なツールで行う方法までさまざまな方法があります。 実務では特定の URL だけをひたすら叩いて・・というテストではあまり意味のある数字が出て来ない事が多く、JMeter を利用してシナリオを作ってテストする事が多いです。 限界まで負荷をかけ続けるのではなくて、秒間リクエスト数(rps)を決め打ちして実行してみてサーバ側の負荷やその他の状態を監視したいというニーズもすぐに出てきます。 さて、JMeter でそのようなテストを実施する場合にどのように行うかというと、これにはいくつかの方法が考えられる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く