最近、本当に悪い問題が発生しました。私の Rails (3.2.12) は、アセットの提供を非常に遅く開始しました。変更されていないアセットが 304 を返すのに丸 1 秒かかっていました。ページの合計読み込み時間は約 20 秒でした。
"GET / HTTP/1.1" 304 - 13.5556
"GET /application.css HTTP/1.1" 304 - 0.8758
"GET /bootstrap.css HTTP/1.1" 304 - 1.5164
"GET /printing.css HTTP/1.1" 304 - 0.8421
"GET /application.js HTTP/1.1" 200 1335651
歴史的に、アプリがこれほど遅いことはありませんでした。
同じアセットの後続のリロードには、0.5 秒以上かかる
"GET /pages/logo-white-topbar.png HTTP/1.1" 200 785 1.0668
"GET /pages/logo-white-topbar.png HTTP/1.1" 304 - 0.6074
"GET /pages/logo-white-topbar.png HTTP/1.1" 304 - 0.5951
"GET /pages/logo-white-topbar.png HTTP/1.1" 304 - 0.6449
"GET /pages/logo-white-topbar.png HTTP/1.1" 304 - 0.6031
問題に関するいくつかの奇妙な点:
- 私の同僚は誰もこの問題を経験していません。このコードベースに取り組んでいる開発者が数人いますが、誰もこの問題を抱えていません。（したがって、コード内の何かの問題ではありません）
- Rails アプリのコードベースには、エンジンのソースが含まれています。他のアプリはそのエンジンを共有しています。他のアプリがエンジンのソースを指している場合、遅くはありません。
だから私は最も簡単なものから始めて難しくなるすべてを試しました：
- アセット パイプライン、アセット デバッグなどのオン/オフを切り替えます...
- git bisect を 6 月に戻す
- Gemfile から可能な限りすべてを取り出す
- Ruby 1.9.2 から 1.9.3 へのアップグレード
- すべての宝石を再構築する
- Ruby 1.9.3 を再構築する
- rvm をアンインストールして再インストールする
- Ruby 1.9.3 を最適化して再構築する
何も機能しませんでした。すべてが遅かった。
最後に、プロジェクト ディレクトリを吹き飛ばし、アプリを再クローンしました。私はそれを実行し、アセットは妥当な時間内に提供されました.
"GET /pages/logo-white-topbar.png HTTP/1.1" 200 2267 0.2029
"GET /pages/logo-white-topbar.png HTTP/1.1" 304 - 0.1827
"GET /pages/logo-white-topbar.png HTTP/1.1" 304 - 0.1822
つまり、ここで世界に火をつけているわけではありませんが、それは劇的な改善です. ページの読み込みは 20 秒から 4 秒になりました。
古いディレクトリと新しいクローン ディレクトリの唯一の違いは、古いディレクトリに 69 個の git ブランチがあることです。明らかに、それらを一掃する必要があります。ほとんどは完全にマージされていますが、一部は長期にわたるフィーチャー ブランチです。
私の質問は次のとおりです。これは正当な問題ですか? 70 のブランチを持つことで、アセット パイプラインのパフォーマンスが本当に低下するのでしょうか? 何故ですか？私の.gitはどういうわけか無愛想ですか？これを処理するには、明らかに git について十分な知識がありません。
これは、OSX 10.8.4 の git 1.8.1.2 です。
ありがとう。
更新: git はニシンであるという Rein の提案により、私は他の犯人を詮索しました。私のログ ディレクトリが巨大なサイズに膨れ上がっていたことがわかりました。私はそれを吹き飛ばしましたが、違いはありませんでした。外部アセット (たとえば、mixpanel から) が 24 ミリ秒で提供されるのはばかげていますが、私のローカル マシンは小さな js ファイルで 304 を提供するのに 1000 ミリ秒かかります。
更新 2: 遅いレポ.git/objects/packでは 104MB であり、ディレクトリには実行後でも大量のルーズ ファイルがあります。git gcpack