お久しぶりです。Ooharabucyou でございます。
当ブログの存在をすっかり忘却しておりましたが、みなさまお元気でしょうか。
最近は、本業ではもっぱら Groovy や Gradle と戯れる日々なので
PHP については、暫く触っていませんでしたが、
PHPMatsuri も近づいておりますので、201千葉コーワーキングにこもり
こうして準備をしているわけでございます。
さてさて、久しぶりの話題は composer でございます。
去年の PHPConference などでも、以下の様な話題で composer の
布教活動などをしました。
あれから、10ヶ月。Github に composer が登場してから、まもなく2年となろうとしております。
PHP勉強会などに参加すると、だいぶ普及してきたように思えます。
Symfony だけでなく、様々なプロジェクトで活用されている成果なのでしょう。
pear でのライブラリ管理よりは(自分の中で)ずっと快適なのですが、
まだ不満はあります。
その一つ、特に囁かれる問題が、遅いという点です。
現在のcomposer の動作をソースコードの確認や -vvv オプションの付加により
なぜ遅いのかを考えてみます。
update 時に -vvv をつけると、より詳細なログが
標準出力に出てくるので、デバッグなどに便利です。
そうすると、見た感じから、以下がストレスを作る原因と考えられます。
遅い1) Package情報の入手
標準では、packagist.org からパッケージを入手する仕組みになって
いますが、この動作は現在2つに分類されます。
1つは、 /packages.json の入手です。このファイルには、
どのように参照すれば実際の依存情報を記したファイルが手に入るのか
という情報を記しています。
このダウンロードは毎回行われますが、さほど時間はかかりません。
問題は次です。上で入手した情報を元に依存情報の収集に向かうのですが、
これが、初回の場合大変時間がかかります。
(プロジェクトの規模によるかと思いますが、Symfony2 で動くプロジェクトであるpackagist の場合、
情報の取得だけで 17MB, 145個のファイルをせっせとダウンロードしていたのでした。)
2回目の場合は、cache から収集するため、 ずっと早くなります。
cache はデフォルトで 6ヶ月有効です。cache の場所は デフォルトでは
$HOME/.composer/cache/ なので、覗いてみるといいかもです。
遅い2) ソースコードの入手
これは、パッケージの定義によりけりです。
通常、安定したバージョンであれば、Github のアーカイブ (zip) から
入手されます。こちらも同様にキャッシュされます。
ただし、開発ライブラリなどであれば、gitレポジトリから clone
する場合が多いため、こちらがなかなか時間がかかります。
(こちらはアーカイブの場合キャッシュされます。
そのため、2回目は早くなります。)
これを踏まえた上で、解決案を考えてみた。
解決案) packagist.org JP Mirror or Proxy を作る
Tokyo から packagist.org まで 300ms – 500ms ほどの
レイテンシが存在するのです。
このサーバは、France にあるようです。ちょっと遠いですね。。。
日本のどっかにサーバを置くことで早くなるんじゃないかという説。
packagist に Nexus (Maven Repository/Proxy) みたいな Proxyの仕組みがあると嬉しいのですが。
* 参考記事: リポジトリ管理ツール「Nexus」でMavenをさらに活用しよう!
そこら辺は、改造のやりがいがあるかもしれないです。
—
【追記】
なお、社内ライブラリやプロジェクトの配布については
composer/satis を使うとよさそうです。
このツールは、Composer Repository のビルドツールです。
ちゃんと設定すると、packagist.org 上の依存ライブラリのアーカイブを
自分のサーバで配布することができます。
自身のプロジェクトで、自分で用意した Repository を使い、
packagist を無効化すると、かなり高速化されます。
あとで、これについての記事を書こうとおもいます。