巨大なリポジトリをサブモジュールに登録していると更新にめちゃ時間が掛かるのをどうにかしたいという記事を Qiita に書きました。
システム開発
CakePHP + MySQL アプリのテスト時間を 72% 削減した話
この記事は CakePHP Advent Calendar 2018 の23日目の記事です。
CakePHP アプリケーションのユニットテストでボトルネックになりがちなのがデータベースへのディスク I/O 時間ですが、そういったプロジェクトでは FriendsOfCake/fixturize プラグイン を導入すると大幅に高速化できる可能性があります。
実例として、テストに18分も掛かっていた MySQL を使ったプロジェクトありましたが、導入後なんと5分にまで短縮されました。(約 72% の高速化🎉)
結果として早いサイクルで CI を回せるようになり開発スピードも上がりました。
何がボトルネックになっていたか?
テストケースごとに実行されるテストデータのリロードクエリがボトルネックになっていました。リロードクエリとは TRUNCATE TABLE
クエリと INSERT
クエリのセットのことで、積み重なると高コストなクエリになります。
テストデータのリロード時間はテストケースが増えるほど支配的なものになる
CakePHP のユニットテストは、テストデータを Fixture クラスとして定義しておき、テストクラスの側で使用したい Fixture 名の一覧を記述します。
例として、テストクラスは以下のようになります。
<?php namespace App\Test\TestCase; use Cake\TestSuite\TestCase; class ArticlesTest extends TestCase { // 3テーブル分のテストデータの使用を宣言 public $fixtures = [ 'app.articles', 'app.comments', 'app.users', ]; public function testCase1() { // テストコード } public function testCase2() { // テストコード } }
このテストを実行すると testCase1()
と testCase2()
のテストケースの実行前に、それぞれ3テーブル分のリロードクエリが実行されます。同じように、このクラスに100個のテストケースがあったとしたらリロードクエリは最低で300回実行されます。
極端な例を挙げましたが、リロード回数はテスト数とフィクスチャ数の掛け算で増えていくため、簡単に無視できない I/O コストになることは想像に難くないと思います。
毎回テストデータをリロードする理由
無意味に何度もリロードしている訳ではありません。毎回リロードすることで、テストが書きやすくなるというメリットがあります。
テスト中にいくらテストデータを書き換えたとしても、次のテストでは元の状態にリセットされているので、テストケース間でテストデータの状態について副作用を気にする必要がなくなります。
この高速化プラグインがすること
FriendsOfCake/fixturize のソースを見ると分かりますが、このプラグインのすることは非常にシンプルです。上述の「毎回同じテストデータの状態でテストを開始したい!」という要求を満たしつつ、必要なときだけリロードするようにし、リロードクエリの実行回数を削減します。
具体的には、初回のフィクスチャロード後に CHECKSUM TABLE クエリ でテーブルのチェックサム値を取っておき、次以降のリロードは差分があったときだけ行うようにします。
チェックサム値に差分がなければテストデータが変更されていないということなので、リロードもスキップして問題ないということになります。
プラグインで高速化できる可能性のあるプロジェクト
ということで、以下に該当するプロジェクトであればプラグインを導入するだけで大幅にテスト時間を削減できる可能性があります。
- CakePHP 3.x 製アプリ
- MySQL / MariaDB / Percona のいずれかを使用している
- テストケース数とテーブル数が多いプロジェクト
- 複数テーブルを参照する結合的なテストをしているプロジェクト
また、もしこのプラグインが使えない環境のプロジェクトであっても、不要なロードを減らすというアプローチ自体は有効かもしれません。
おまけ: その他のアプローチ
他のアドベントカレンダーになりますが、素晴らしい記事を見かけましたのでそちらも紹介しておきます。
DB ストレージを tmpfs というオンメモリのファイルシステムに差し替え、高コストなディスク IO を無くすることで高速化するというアプローチです。私も手元のプロジェクトで試してみましたが、実際に 40% ほど高速化できました。FriendsOfCake/fixturize プラグイン と併用することで更に高速化が見込めます。
試しに手元の1500個ほどテストケースがあるプロジェクトで試してみたら、記事に書かれてる通り40%くらい削減できた。やったことは二行追記するだけ。すばらしい。
— そわそわ (@ymm1x) 2018年12月19日
シェルスクリプトで暗記カードを作った話
突然ですが Jan. や Feb. といった月名の略称を見たときにそれが何月かスムーズに思い出せますか?
思い出せる人はとてもえらいです。ちなみに私はさっき Jun. という文字を見て何月か思い出すことが出来ずショックを受けました。June ってなんだか6月感が薄いと思うんですよね。どうしようもない話ですみません…。
8月 August → わかる
7月 July → わかる
6月 June → わからないなぜなのか
— そわそわ (@ymm1x) 2018年12月13日
何とかするためシェルスクリプトでサクッと暗記マシーン(?)を作ることにしました。
動いてるところ
ランダムに問題を出題し、答えるだけのシンプルなツールです。
CTRL-C キーなどでスクリプトを終了するまで無限に出題され続けるスパルタ仕様になっています。何度かやって無事に覚えることができました🙆
ソースコード
なるべくシェル芸感は薄めて、前に書いた シェルスクリプトを高級言語のような書き味に近づける Tips 集 の内容を取り入れた実装にしています。
#!/usr/bin/env bash set -Ceuo pipefail # 出題する問題集を定義 # スペース区切りで問題とその回答を記述しておく readonly QUESTIONS=$( cat <<FIN Jan 1 Feb 2 Mar 3 Apr 4 May 5 Jun 6 Jul 7 Aug 8 Sep 9 Oct 10 Nov 11 Dec 12 FIN ) # 色付きの echo 関数 function cecho() { local color_name color readonly color_name="$1" shift case $color_name in red) color=31 ;; green) color=32 ;; yellow) color=33 ;; *) color=30 ;; esac printf "\033[${color}m%b\033[m\n" "$*" } # 標準入力で渡された全行の中から # ランダムに一行を取り出すフィルタ関数 function rand_line() { cat - | perl -MList::Util=shuffle -E 'say shuffle(<STDIN>);' } # 標準入力で渡された一問を出題する関数 function ask_question() { # 区切り文字を半角スペースでスプリットし、 # $question と $answer に代入する IFS=" " read -r question answer # 出題文を表示する echo "[Q] $question" # 回答の入力待ちをする read -rp "[A] " input </dev/tty # 入力された回答を答え合わせ if [[ $input == "$answer" ]]; then cecho green "正解" else cecho red "不正解 (正解は「${answer}」でした)" fi echo } # ランダムに一問を出題する関数 function ask_any_question() { # 問題集を出力する echo "$QUESTIONS" | # 全問題の中からランダムに一問を取得する rand_line | # 取得した一問を出題する ask_question } function main() { echo "表示される月の略称が何月か回答してください!" echo # 出題を繰り返すメインループ while true; do ask_any_question done } main
回答の入力待ちは無くしてランダムに出題と回答表示を繰り返すだけのほうが暗記カードっぽくなるかもしれませんね。
月名に限らず、問題集の定義を書き換えれば英単語の単語カードなどでも使えるとおもいます。出来れば問題データは別ファイルに定義した方がいいですが今回は省略したいとおもいます。