メインコンテンツまでスキップ

「Javaの鉱脈」でGatlingの記事を書きました

Sato Taichi

WEB+DB PRESS の Vol.83 で、負荷テストの記事を書いたので是非読んで頂きたい。

2014/10/24 発売ですので、既に購入頂いてる方も多いと思います。

電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。

今回の記事における対象読者について#

JMeter だ、JMeter を撃滅せよ。

負荷テストスクリプト書くのに GUI なんぞいらないのですよ。 素人騙すんなら、それでいいかも知らんけども、そういう事じゃないでしょう。

GUI なしでも書けますよって、そのヤヴァイ XML を俺に見せるな。

負荷かけてる最中にサーバより先に死んだりするような負荷テストツールを後生大事に使うのをやめて欲しいのです。

今回は、新進気鋭のツールであるところのGatlingを紹介しましたけども、実績があるツールを使いたければGrinderをオススメします。

正直に申し上げて負荷テストって恐ろしく難しい種類のテストなんですけども、特にその難しさについては書いていませんので、きっと名古屋辺りのうさぎさんが補足資料を提示してくれるでしょう。よろしくお願いします。

僕の観測範囲だと、ab で雑に負荷かけて何となく OK みたいな事やってる人達とか、結構頑張ってる感ある人でも JMeter で頑張ってますみたいな酷い状況を少しでも改善したい。

負荷テストって、有償のソフトウェアからハードウェア付のラグジュアリーソリューションまで、大変に高価なものもあるのですけども、そういうものに対するイニシャルコストを平然と支払うためには少なくとも負荷テストがどのようなものであるのか、適切に理解した上で使いこなせないと意味がないので、まずは無償だけどもちゃんと動いてくれるツールを使いましょうと言いたい。

DevOps とかいう単語が世間を賑わせているような感じがしないでも無いですけども、プログラマの皆様におかれましては、その最近ちょろっと覚えた Scala を使って手元のウェブアプリケーションの負荷テストをしてみませんかね。

いきなり Scala でデカいアプリ作ろうったって、そうはいかねぇよ。周辺部分で失敗してもリスクが少ない割にリターンのデカい部分で新しいテクノロジは試そう、な?

インフラエンジニアがアプリケーションの負荷テストを完全にやってくれるような時代はもう既に終わってる(もしくはそんな時代は無かった)んで、プログラマもユニットテストの延長くらいの気持ちでカジュアルに負荷テストしましょう。マイクロなパフォーマンスチューニングを定常的にしろってんじゃないので、そこはお間違えの無きよう。

記事の内容について#

Akka は最近注目を浴びている感じがしないでも無いので、それを基盤に使っているという事で Gatling を選んだのですけども記事を書いている最中に Gatling が Akka の極めて重大な機能を適切に使いこなせていない事が分かり、青ざめたりもしました。

それが何なのかは記事を読めば分かる筈なので気が付いたら、ツッコミ入れてくれると嬉しいです。えぇ。

最後に#

他人のサービスに負荷テストツールで負荷かけると犯罪です。自分たちで用意したサーバに対して使いましょう。

AWS みたいな IaaS 使ってる場合は、負荷テストの前に申請が必要なことが多いので注意してクダサイ。