82
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

posted at

updated at

Organization

packagist.orgのミラーサーバを立ててcomposer updateを18倍速くする #packagist

現状報告はこちら

packagist.JPの現状について(2015年12月): Architect Note

以下原文

PHPのモダンな依存関係解決ツールであるcomposerですが、動作が遅いですよね。
私も常日頃から遅さを実感しており、何とかしたいと思っていました。

つい先日、GCを切るというハックによってだいぶ速くなりましたが、それでもpackagist.orgからのダウンロード部分は変わらず遅いままです。

Composer を倍速にした、たった 1 行のコード - Shin x blog

例えば、symfony/symfonyのインストールを考えてみます。

# ベンチマーク用の環境準備
$ mkdir composer-bench
$ cd composer-bench
$ composer require 'symfony/symfony:*'

# ベンチマークの公平性のためメタファイルのキャッシュだけ消す
$ rm -rf ~/.composer/cache/repo/https---packagist.org

この状態からcomposer updateしようとすると、これぐらい時間がかかります。(測定環境によってこの時間は大きく変わります。以下は私が試した結果です。)

$ composer update --dry-run --profile
[7.6MB/0.15s] Loading composer repositories with package information
[8.1MB/2.37s] Updating dependencies (including require-dev)
[111.3MB/309.87s] Nothing to install or update
Memory usage: 92.52MB (peak: 111.54MB), time: 309.9s

全く同じコマンドを直後に打つと、キャッシュが効いているのでもう少し早くはなるのですが、updateをうっかり打つと5分かかるとは、、ちょっと遅いですよね。。

composerが遅い理由

いくつか理由があります。

  • packagist.orgが日本から遠い
  • composerのアーキテクチャ的に、小さなjsonファイルを少しずつダウンロードするため、ネットワークの遅延がもろに影響する
  • composerがfile_get_contentsでjsonをダウンロードしていて、どうやらKeep-Aliveを使っていないし、並列ダウンロードもしていない

私は「composerがそもそもイケてないのだ」と思ったのですが、ソースコードもそれなりに巨大ですし、本体に手を入れるのは大変そうでした。

そこでミラーサーバ

コマンド一発で5分はあまりにアレなので、さくらVPSを使ってミラーサーバを作ってみました。

ドメインが何故か空いていたので確保しました。

$ composer config -g repositories.packagist composer https://packagist.jp

こんな感じで、composerの設定に入れておくと、packagist.orgの代わりにこのミラーサーバを参照するようになります。設定を有効にした状態で先ほど5分もかかったcomposer updateを打ち込むと…

# ベンチマークの公平性のためメタファイルのキャッシュだけ消す
$ rm -rf ~/.composer/cache/repo/http---packagist.jp

$ composer update --dry-run --profile
[7.6MB/0.15s] Loading composer repositories with package information
[8.1MB/0.21s] Updating dependencies (including require-dev)
[111.2MB/16.73s] Nothing to install or update
Memory usage: 92.5MB (peak: 111.53MB), time: 16.75s

なんということでしょう。300秒が16秒で 18倍 ぐらい速くなってますね。これぐらいなら我慢できる範囲に収まるのではないでしょうか。

あくまでpackagist.orgとの通信がショートカットされるだけなので、ソースコード本体をgithubからダウンロードするところの速度はあまり変わらないかもしれません。あしからず。

ミラーサーバの中身

ミラーといっても完全なコピーではなく、composerコマンドに必要なファイルだけコピーしています。

composerはinstallやupdateコマンドを打つとpackagist.orgに問い合わせに行き、いくつかのJSONファイルをダウンロードします。このJSONファイルを前もって全部ダウンロードしておき、普通にApacheやNginxでJSONを配信すれば、ミラーサーバが出来上がります。 SolrとかMySQLとかは立てなくて大丈夫です!!

JSONファイルもクロールしやすくできていて、

https://packagist.org/packages.json
がまずあり、この中にパッケージ一覧が書かれたJSONファイルが4つ書かれています。

active, archive, latest, staleの4つのjsonファイルをダウンロードすると、それぞれの中に更にパッケージごとのJSONのパスが書かれているので、それらを上から順にダウンロードしていけばpackagist.orgの全データがコピーできるというわけです。

この辺のロジックと、あと高速にダウンロードするためのセッション管理、キャッシュ管理なども含めたスクリプトをgithubに置いているので、ミラーサーバを建てたい方は参考にしてみてください。
https://github.com/hirak/packagist-crawler

なお、packagist.jpの場合、packagist.orgとの同期は2分おきです。なので、最新のパッケージが反映されるまで最大2分のラグがある可能性があります。

必要なサーバスペック

JSONを全部ダウンロードすると500MBぐらいになります。意外と少ないですね。packagist.orgはあくまでパッケージのメタ情報だけを管理していて、ソースコード本体はgithubなどから配信しているので、これだけコンパクトなのです。

もちろんこれからパッケージが登録されるにしたがってデータ量も増えるはずですが、せいぜい数GBのディスクがあれば十分という感じですね。

あとは普通のWebサーバーとしてJSONを配布すればいいので、共用タイプのレンタルサーバーとかでも全然使えます。ただ、細かい静的ファイルを高速に配信できた方がいいので、チューニングを工夫すればもっと速くできるのかもしれません。

composer-proxy.jpとの比較

Composer Proxy JP
こちらは @ooharabucyou さんがメンテナンスされているpackagist.org専用のプロキシサーバです。

私も最初はcomposer-proxy.jpを使っていたのですが、あくまでプロキシなので、誰かがファイルをダウンロードしてくれないとキャッシュされません。キャッシュされていないファイルをダウンロードしようとすると、その人の体感速度はpackagist.orgを使っていた時と変わらないのです。

有名どころのパッケージだけを使っていればまだよいのですが、packagist.orgに個人的なパッケージをいくつか登録している身としては、そんな自分専用のパッケージを使ってくれる人は他におらず、しょっちゅうキャッシュヒットしない状態でした。

そういうわけで他にいい方法はないか考えてみて、自分用にミラーサーバを作るに至った感じです。

今後の展開

作れるかなーと思ったら案外簡単に作れちゃった、という感じなのですが、正直今後どうするかに困っています。

ダウンロードするJSONファイルはpackagistに登録されたパッケージ数だけあるので、今だと44,000ぐらいのファイルをダウンロードする必要があります。
日本のPHPerがこぞってミラーサーバを作ると、packagist.orgへのDOS攻撃になってしまいます。
(ちなみにこのミラーサーバを作るにあたって、packagistには何の許可もとっていません。怒られたらヤバいかもしれません。。)

中の人にメールして、2分おきぐらいだったらいいよ、という言質を取りました。大丈夫そうです。

ちゃんと運用していくなら、もっと権威のあるどなたかにお任せして、「日本のPHPerはみんな安心してこのミラーを使えばいいよ!」っていう風にしたいのですが、誰に相談すればいいですかねえ…

一応、ミラーサーバ自体は先述の https://github.com/hirak/packagist-crawler を使ってcronで定期的に同期すれば割とすぐ作れるようにはなっています。

追記(2015/01/03)

一応きちんとしたドメインを、ということでpackagist.jpを取得しました。
私が生きているうちは面倒を見るつもりですので、自由に使っていただいて構いません。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
82
Help us understand the problem. What are the problem?