laravelでのAOPをあきらめてみる - kazu22002の技術覚書

phpでドメイン駆動をやろうと試行錯誤していて、aopを使おうとプロジェクトにいれていましたが、速度が遅くなりすぎたため断念しました。

使っていたのはRay.aopのlaravel用にラップしてあるライブラリを使用。

コードが肥大化してきて速度が遅くなってしまったのかと思っていたが、調査したところaopを使用しない場合には速度がかなり速くなったためaopの使用を断念しました。

調査する前は平均で１アクセスで1000ms〜5000msかかっていましたが、改善した結果200msぐらいになりました。これが普通ですよね。

php難しいねー

今回の原因としてちゃんと調べた内容ですが、laravel-debugbarを利用しboot部分、処理部分の時間確認、メモリを確認しました。

確認ページは初期のwelcomeページで試しています。

調査前の平均

boot : 1500ms
main: 10ms
メモリ: 50MB

bootに時間がかかっているらしい。メイン処理には時間がかかっていない。メモリ量も異常に多い。

laravel初期の状態で試した場合

boot : 80ms
main: 10ms
メモリ: 5MB

比べてみるとlaravel自体が悪いわけではなさそう。十分に早い。

boot部分に時間がかかっているため、コード量が増えたのが悪いと思い、初期状態のlaravelプロジェクトに肉付けしながら時間を計測。

順番に追加、削除をしてaop周りで遅くなっているのを確認。

aopを使用しなければ早いことはこの段階で理解。

aopを使っているclassが50以上あったので影響あるクラスを減らしていきながら速度、メモリを確認。

aopを利用するclassが1つ増えるごとにメモリが1MB増え、時間も徐々に増えていきます。

ほぼaop部分で読み込み量が増え、時間がかかるようになっているみたいです。

実現してる仕組み上問題がありそうですが、phpにできないことが多いのでしょう。

phpのautoloadを利用すると、処理時に必要なファイルのみメモリに展開され実行されます。

get_included_files関数を利用することで読み込んだファイルを確認することができます。

これを利用して展開されているファイルを確認すると、aop周りのファイルが利用されていない処理でもすべて読み込みがされる状態になっており、毎回多くのファイルを展開していることになります。

影響としてboot部分で読み込み処理が発生し、時間がかかることになっていたみたいです。

原因がわかったので、使わないようにプログラムを書き換えて終了しました。

laravelでのaopは使わないようにします。

Ray.Aopを利用していますが、素の状態でつかったことがないため同じ現象になるかは不明です。

Bear.sundayはつかってみたいフレームワークのため今度つかってみる機会を作ってみます。