スローテスト刑事 (デカ)

スローテスト刑事�(デカ) Powered�by�Rabbit�2.1.8
スローテスト刑事
(デカ)
第74回�Ruby関⻄�勉強会
京都⼥⼦大学�C508
2016-09-11�(Sun)
伊藤�浩⼀�(@koic)
(株)永和システムマネジメント

わたし

わたし
(株)永和システムマネジメントで
働く会社員。Rubyとかメタルと
か好きです。
https://github.com/koic✓
https://twitter.com/koic✓
https://koic.hatenablog.com✓

�

御礼

今⽇の話
Railsアプリケーションのスロ
ーテスト対策について
✓
XP�で伝えられる�Testing�と�
Continuous�Integration�への
現実的課題点について考察
✓
現場での実践とポイント
オンプレJenkins✓
✓

まとめ

Thanks�(デカ部屋)
@1syo✓
@onk✓
@yattom✓

フルビル
ド何分で
すか？

とあるアンケート
10分以内に抑えるようにして
います

10分と
いう目標

目標と現
実の差を
知る

ある現実
だいたい3,795�examplesほど✓
ある時点で�rake�stats�した
Code�LOC:�12796✓
Test�LOC:�23518✓
Code�to�Test�Ratio:�1:1.8✓
✓
素朴にテストを書いて実⾏とか
だと1時間越え
✓

1時間越え
24つのPull�Requestが出たら
1⽇の処理量を越える
✓
というか翌朝出社しても終わら
ない
✓
ないわー✓

86,400

時間の重み
1⽇は86,400秒✓
例えば60秒かかるスローテス
トが30つあると、
✓
⼀⽇に処理できるCIの上限は
48つ以下
チームは⼀⽇何回のコミットをして
ますか？
✓
✓

⾦を払いま
すか？労⼒
を払います
か？

最速での事件解決法
札束で殴る✓
潤沢な⾦と権⼒✓
お⾦がんばれ✓

労⼒を⾦で解決する
問題解決の基礎戦略のひとつ✓
潤沢な⾦と権限のあるプロジェ
クトは動きやすい
あまりそういったプロジェクトばか
りでないのが現実
✓
今⽇の話は制約の中でどうしていく
か
✓
✓

スローテスト刑事�(デカ)�の
⽇常
テストの並列化と個別のチュー
ンナップを頑張る
✓
まるで靴底をすり減らした聞き
込みのように地道な作業
デカだからね✓
✓

TL;DR

コアでスケー
ルアウトしメ
モリでスケー
ルアップする

私のオススメ
倍速レベルで速くなる並列化を
初⼿にすると良い
投資対効果が⾼い✓
✓
DBのデータファイルのメモリ
化でディスクIO削減
RDBMS自体のパフォーマンスが上
がるわけではないので、20%の速度
向上など⼀定⽐率で頭打ちはある
✓
✓

Topics
1.�Parallel✓
2.�DB✓
3.�Tips✓

1.Parallel

Gemﬁleに以下を書いて
bundle�install�(1/4)
parallel̲tests�/�test-queueとい
った並列化ライブラリがある。
��
ここはparallel̲testsを例にする。

各種設定を並列対応�(2/4)
データベースを並列分用意して、
conﬁg/database.ymlを対応する
��
��
RDBMSに並列実⾏分のスキーマ�
(あるいはDB)�を用意する
✓

並列分のスキーマ作成�(3/4)
rake�db:migrate�の実⾏より�
rake�db:schema:load�の⽅が速い
ので意図がないならオススメ
��
��

テストの並列実⾏�(4/4)
--suﬃxでテスト対象を絞り込んで
⾒てみても良い。
��
��

効果
4コア:�約1時間のテストが約
15分になった。
✓
2コア:�約1時間のテストが約
30分になった。
✓

共有リソースが容疑者
基本的に個別のテストに⼿を⼊
れず効果を得られる
✓
Isolated�Testの原則からそれ
ぞれが影響しないはず
✓
Shared�resourcesに気をつ
ける
逆にいうとだいたいここくらい✓
✓

並列化まとめ
tmm1/test-queue,�grosser/
parallel̲testsなどで並列化
✓
並列化するためデータベースや
全⽂検索エンジンなどのリソー
スも並列可能にする
✓
コアの数でほぼ頭打ちになるの
でハイスペックのマシンが良い
✓

効果が⾼い
ので最初に
やると良い

2.�DB

データファイルのtmpfs搭載
RDBMSによるが2割減などが
⾒込めたりするらしい
✓
⼀⽅でDisk�IO減は思いのほか
効いていない
✓
というかこの間、Vagrantのパ
ラメータやらtmpfs化と合わせ
てしておくREDOログの設定し
くっててMac�MiniのCI死んだ
✓

Vagrantメモリ割当の変
問題.�この設定で�vagrant�reload�
してテストを流しました�(配点2点)
��
��
��
��
��
��

まだ⽣傷が
癒えていな
いので割愛

データベースのクリーニング
を整理する
スローテストの原因は、だいた
いデータベースがネック
CI�実⾏もアプリケーションでの実
⾏もボトルネックは同じ
✓
✓
amatsuda/
database̲rewinderというプ
ロダクトもあるが、ここでは
DatabaseCleanerのお話
✓

DatabaseCleaner.strategy

spec̲helper.rb
あるいはrails̲helper.rbに以下が
あれば⾼速化の狙い目。
��
��
��
��
��
��
��

DatabaseCleaner.strate
gyはできるだけ
transactionに任せる
データベースのデータ挿⼊と取得
で異なるスレッドが現れる
JavaScriptのテスト以外は
truncationではなく、同⼀スレッ
ドで扱えるtransactionにする。

容疑者探し
example.metadata�が⼿掛かり。
��
��
��
容疑者の絞り込みまで出来るとあ
とはやるだけなので割りと楽。

やること
@javascriptを必要な場所に移す
��
��
��
��
��
��
��
��
��

効果�1�BEFORE
��
��

効果�1�AFTER
��
��

効果�2�BEFORE
��
��

効果�2�AFTER
��
��

効果�3�BEFORE
��
��

効果�3�AFTER
��
��

効果�4�BEFORE
��
��

効果�4�AFTER
��
��

全体効果
約40分のテストが35分になっ
た。
9%ほど削減✓
✓

あとは地道に細かいチューニ
ング
投資対効果が⾼いテストからチ
ューニングしていく
✓

3.Tips

プロファイリング
推測するな、計測せよ�(--proﬁle)
��
��
��
��
��
��
��
��
��
��
オリコンチャート的な。

sleepを取り締まる
grep�sleep�.�|�wc�-l�で⾒つか
った件数以上の待ち時間が発⽣
スローの原因場所は⾒つけやすい✓
✓
JavaScriptの関わるE2Eテス
トでの遭遇率⾼い
✓
1秒もsleepするならDBに状態
を問い合わせた⽅が速い
✓

DRY
テストの重複を消す✓
コピペによる迷宮⼊り✓
コードを書いた時点でないと⾒
つけることが現実的には困難？
Code�Climate的な静的解析で⼿掛
かりを⾒つけたりできる？
✓
知⾒を知りたい✓
✓

断捨離
使われていないテスト�(と呼び
出される不要な)�コードを捨て
る
✓
⾜し算より引き算の⽅が難しい✓
コードを捨てることができて⼀
⼈前
✓

最適化
before(:all),�before(:each),�
aggregate̲failures�あたりの
最適化
✓
毎回の初期化が必要かどうかは
⼀考の余地有り
✓
最近は�1�example(it,specify)�
で�1�テストケースよりも速度
重視に思考が変わってきた
✓

できるだけインメモリ
不要な�AR�オブジェクト作ら
ない�(factory�で関連作らず�
nil�にしておく)
✓
DB�にアクセスさせない�
(FactoryGirl.create�->�build)
✓

system�呼び出さない
他のテストで担保している遅い
外部コマンド�(ImageMagick)�
をスタブ化するなど
✓

無駄な処理
サムネイル作らない✓

付録

対象絞り込み
変更と関係のあるテストだけ実
⾏するという選択肢
✓
タグ(rspec�--tag)で対象のテ
ストを絞る
ただし全テストを⾒たいCIの前段ま
で
✓
✓

ci�skip
rails/railsはじめ常套⼿段✓
コメント修正といったレビュー
をパスすれば良いだけのものは
テストしない
CI�の設定✓
✓
ci�skip�/�CI�SKIP�/�skip�ci�/�
SKIP�CI�いずれでも受⼊れるよ
うにしておくと良い
✓

To�be�continued...
スローテスト刑事�(デカ)�の捜
査は続く
✓

Dying�Message
札束で殴る✓
潤沢な⾦と権⼒✓
お⾦がんばれ✓

スローテスト刑事 (デカ)

More Related Content

More from Koichi ITO

スローテスト刑事 (デカ)