RE: Significant checkout performance degradation between 1.6.1 and 1.7b2

Here're the test results for the basic merge repository:

Subversion 1.7.0 Beta 3, binaries from collabnet
Basic Tests:
| 1.7.0-beta3 | rNNNNNNNN | 0:54.539 | 0:47.774 | 0:00.214 | 0:00.075 | 0:00.101 | 0:01.187 | 0:01.365

Merge Tests:
| 1.7.0-beta3 | rNNNNNNNN | 0:08.154 | 0:08.984 | 0:08.402 | 0:13.511

Folder Tests:
| 1.7.0-beta3 | rNNNNNNNN | 8:37.779 | 0:01.282 | 0:14.041 | 0:31.032 | 0:08.727 | 0:38.879 | 0:34.304 | 0:08.458 | 0:40.519

Binaries Tests:
| 1.7.0-beta3 | rNNNNNNNN | 0:00.046 | 0:00.030 | 0:00.029 | 0:00.027 | 0:00.025 | 0:00.029 | 0:00.029 | 0:00.028 | 0:00.030 | 0:00.031 | 0:00.023 | 0:00.031 | 0:00.030 | 0:00.031 | 0:00.030

**********

Subversion 1.6.17, binaries from VisualSVN

Basic Tests:
| 1.6.17 | rNNNNNNNN | 0:42.548 | 0:39.758 | 0:16.504 | 0:00.257 | 0:00.105 | 0:00.637 | 0:02.445

Merge Tests:
| 1.6.17 | rNNNNNNNN | 0:11.664 | 0:02.343 | 0:14.951 | 0:24.941

Folder Tests:
| 1.6.17 | rNNNNNNNN | 11:58.850 | 0:04.826 | 1:53.336 | 3:34.584 | 0:02.681 | 5:30.473 | 1:41.592 | 1:50.339 | 1:49.615

Binaries Tests:
| 1.6.17 | rNNNNNNNN | 0:00.062 | 0:00.035 | 0:00.030 | 0:00.031 | 0:00.030 | 0:00.037 | 0:00.029 | 0:00.030 | 0:00.029 | 0:00.027 | 0:00.026 | 0:00.030 | 0:00.031 | 0:00.028 | 0:00.030

And just to make the comparison easier, I've rerun the test with our repository on the same machine as the benchmark:
svn 1.6.17 takes 5 minutes, svn 1.7.0 b3 takes 8 minutes for a complete checkout.

The server's a Windows 2008R2 with collabnet's svn server 1.6.4. The client's also a Windows Server 2008R2. They're connected in a switched network, with a latency < 1ms.

Our repository is open source, so, in case you believe it helps with benchmarking/finding the bottleneck, you're welcome to exporting the trunk (https://svn.re-motion.org/svn/Remotion/trunk/) and creating a new benchmark repository. Am I correct in my assumption that building a new repository based only on the latest revision of the trunk would result in similar performance figures given it appears to be a client related issue?

Is there any additional information I can provide to help figuring this out?

Btw: I noticed while copying the performance numbers that the switch performance is also greatly improved. That's awesome news! We have some projects that do lot's of branching but aren't pursuing git/hg yet.

Regards, Michael
Received on 2011-08-10 20:02:38 CEST