Laravel Advent Calendar 2017 24日目の記事になります。

Laravelを1年ほど使って得た知見

Laravelは使いやすいフレームワーク
でも、使いやすさに甘んじると途端にパフォーマンス劣化して死ぬぞ
レイヤの分離はしっかりと出来ているので、すべきことを意識して使えば回避は可能
個別のコードは読みやすいと思います。F/Wのコードを読んで適切に使いましょう

はじめに

主に5.2系での知識となります
- 前日に滑り込みしたこともあり、5.3系以降を調べてというのは断念しました

Middlewareはアクセス管理に便利

みなさん、Middleware使っていますか？
@mpywさんが書かれていましたが、Routingのグルーピングはとても便利です。
Routing::groupは特定の権限グループを表現することに非常に適しています
同一の権限を有する場合は認証処理の後に適切な権限をチェック
- 実際にロジックを持つのはPolicy層やService層であるでしょう
- また、データの取得結果はRequest::mergeを使うことで後続処理に引き継げます
- $requestを持ちうるMiddleware層ならではのパワフルな機能です

$request->merge([
    'foo' => 'bar',
]);

架空のマーケットプレイスで例示すると下記の様な4つの権限が出現するでしょう

管理者

新規店舗の認証
各店舗の売り上げの把握
悪質な店舗の取り締まり

店舗管理者

プロフィールの編集
商品の陳列

登録ユーザ

商品の閲覧
購買
購買履歴の閲覧

未登録ユーザ

商品の閲覧
ユーザ登録

Request層にバリデーションを任せる

コントローラ層へのアクセスをする前にバリデーションを終わらせましょう
- ただし、リクエスト層のパフォーマンス劣化はベンチに引っかかりにくいものです
今年は下記の2つのバリデーションルールでパフォーマンス劣化を経験しました
- いずれもPOSTされたデータが巨大であったためです

existsルール

existsルールは都度レコードが存在するかチェックを行います
そのため、発行回数が予測できない場合は避けた方がよいでしょう
回避策としてRequest::validationDataで既存のIDのリストを作成してinルールに置き換えるといったことを行いました

sometimesルール

これはパフォーマンス劣化を起こしそうにありませんが、下記の理由で劣化を招きます
1. sometimesメソッド呼ばれる
2. explodeRulesメソッドが経緯によらず呼ばれる
3. パラメータのキーがワイルドカード指定されている場合にeachが呼ばれる
4. eachメソッドがArr::dotを利用する
5. Arr::dotは再帰処理を行うため、階層が深い場合にハングする
回避策としてワイルドカードの指定を避け、ループカウンタを用いてバリデーションルールを適用するといったことを行いました

Controller層はシンプルに保つ

ファットコントローラは避けましょう
自身のコントローラの役割は下記の様なものだけとしています
- サービス層からデータを取得
- 更新処理であればトランザクションの制御とデータの更新
同じアクションだが権限が違うといったケース
- 継承でなく、ルーティングを用いて権限チェックだけを変えるといったことをしました
ちなみにConnection::transactionは複数DBのロールバックをサポートしません
- 個別にトランザクション処理を行うメソッドを用意すると幸せになれるでしょう

Facadeのスタティックアクセスでは参照渡しが使えない

Facadeを通して提供されたメソッドは下記の理由で参照渡しでは無くなります
- Facade::__callStatic が参照渡しをせずに元のメソッドを呼び出す
- 結果、与えられた引数への変更は__callStaticで止まってしまう
- オブジェクトであれば問題ありません
- 自分がハマったのはRDBMSの取得結果をキャッシュする配列を渡していたため

Service層はビジネスロジックを置き、一つのことをうまくやる

データストアへのアクセス、ビジネスロジックだけを置く様に心がけています
- リポジトリ層があればデータストアへのアクセスはそちらに任せられますね
とはいえ、サービス層の肥大化や複雑化は相変わらず難しい問題です
これらの問題を解決するために一つのことをうまくやることを心がけています
Eloquentは遅いので、パフォーマンスがシビアに要求される箇所ではConnection::selectを使いましょう
- 3倍程度の高速化が見込めます
- ただし、モデルのコレクションでなくstdClassの配列が返されます

Model層にデータ自身が持つべき振る舞いを閉じ込める

モデル層はエンティティであることを自覚しましょう
- EloquentとつながっているのでDBを意識してしまうが、振る舞いの置き場と限定してしまえば幸せになれます
Model::newCollectionをオーバーライドしてカスタムコレクションを返却できます
カスタムコレクションにソートやフィルタ等のメソッドを置くといったことを行っています
updatingやupdatedは呪いと化す恐れがあるので使わない様にしています
- 便利ですが、ストアド同様に気付きにくいバグを生む恐れがあるためです
また、Model::insertに配列を食わすとバルクインサートを発行してくれます
- saveは不要なクエリ発行をしないのでありがたいですが、大量データのINSERTのみ発生するのであれば、適用を検討する価値はあると思います。

Collectionは便利だが遅い

配列の方がパフォーマンスははるかに高いです
パフォーマンスが要求される場面では配列を使いましょう
Collection::pushし続ける処理は配列を作成してcollect($foo)に置き換えると3枚程度、処理が高速になります
- Connection::selectが高速なのはこのため
たとえば下記の様な処理な置換が可能です

// これは遅い
$list = collect();
foreach (range(1, 100) as $i) {
    $list->push($i);
}

// こうしたほうが高速
$list = [];
foreach (range(1, 100) as $i) {
    $list[] = $i;
}
$list = collect($list)

最後に

前日に空きが出ているのに気付いて駆け足になりましたが参加できてよかったです