ライブ サーバーで実行svn updateすると、完了までに 15 分以上かかることがあります。
- 私たちのリポジトリは非常に小さく、約 1Mb でファイル数は 100 以下です (小さな Web サイトです)。
- コミット/更新の両方を行う開発者が数人いますが、これは非常にうまく機能しています
- サーバー上のすべての変更を更新します (これは のみを行います
svn update)、これは非常に遅く実行されています - サーバーからのアクセスは一度もありません
svn commit(サイトの読み取り専用バージョンであるはずです)。
svn update時間が経つにつれて、更新が必要なファイルが 1 つだけであっても、サーバー上での処理がますます遅くなるようです。サーバー上のリポジトリの「年齢」は、リポジトリの遅さに関係していると思い始めていますか? もしそうなら、それをスピードアップするために私たちができることはありますか?
更新 #1
私はまだ「年齢」がsvn update遅いことに関係していると思いますが、サーバー上でリポジトリが「古く」なったときに実際に何が起こっているのかを考慮する必要があるかもしれません...
私がそう思う理由は次のとおりです。
- 2010 年 1 月以降、WebsiteA のリポジトリをチェックアウトし ( を使用
svn checkout)、定期的に更新しています ( を使用)。svn update - また、同じ方法で WebsiteZ の同じリポジトリをチェックアウトしましたが、これはほんの数日前、つまり 2012 年 7 月に発生しました。
- WebsiteA と WebsiteZ の両方が同じ物理サーバー上にあり、どちらも同じリポジトリを使用しています
svn updateリビジョン 100 から 101 に更新するために Web サイト A で実行すると、20 分以上かかります- WebsiteZ で実行
svn updateしてリビジョン 100 から 101 に更新するには、わずか数秒しかかかりません
私が見ることができるこれらの Web サイトの唯一の違いは、WebsiteA がもう少し長く存在していたことです。Web サイト A にはいくつかの余分なファイル (キャッシュされたコンテンツ) がある場合がありますが、これはごくわずか (20 ファイル未満) であり、キャッシュ ファイルを含むディレクトリは svn:ignore を使用してすべてのファイルを無視するように設定されています。
ネットワークの問題を除外することはできなかったと思いますが、WebsiteA と WebsiteZ は同じファイアウォール設定を実行し、ルールがあれば「遅延」ではなく「ブロック」になると思います。両方の Web サイトが同じサーバー上にあるため、ネットワークの問題に関しては、両方とも同じ時間で更新する必要があると思います。
更新 #2
svn update file.txtこれを行うと、非常に高速に実行されることに注意してください。あたかも svn がディレクトリ内のすべてを比較して、何を更新するかを判断しているようです。
更新 #3
最終的にsvnをアップグレードし、チェックアウトしたすべてのリビジョンをアップグレードしました。svn update今ではずっと速く走っているようで、指を交差させてもそのままです。助けてくれてありがとう！
更新 #4
確かに、新しいチェックアウトを行うと問題は解決しましたが、数日/数週間だけでした. ついに今日、svn が遅い原因を発見したと思います。Zend_Auth を使用し、すべてのページで Zend_Auth::hasIdentity() を呼び出して、ユーザーがログインしているかどうかを確認します。この呼び出しによってセッションが作成され、サーバー上にセッション ファイルが作成されます。ブラウザ (または googlebot) が Cookie をオフにしてブラウジングしている場合、リクエストごとに 1 つのセッション ファイルが作成されます。したがって、セッション ディレクトリには何百万ものファイルがありました。ディレクトリ内のファイルを削除し、hasIdentity() を呼び出す前に Cookie が設定されているかどうかを確認して、ユーザーがログインしているかどうかを判断する方法を修正しました。svn更新は 30 秒未満で実行されるようになりました。