<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
I have been running some benchmarks today to test the performance of
"bzr branch" using various source and destinations. The conclusions are
quite informative. In the tests I used 3 different machines directly or
indirectly:<br>
<br>
<ul>
<li>files01 - the NFS file server. This was used both as a host
location for the repository and as the destination for the branch.</li>
<li>cms01 - this was used as a server with a local repository on
either the files01:NFS disk or its local disk and as a client using
the files01:NFS disk or its local disk (a striped RAID)<br>
</li>
<li>desk01 used as a client using either the files01:NFS disk or
a local disk</li>
</ul>
The files01 and cms01 are connected by a 1000 megabits per second link.
desk01 has a 100 megabits per second link.<br>
<br>
Two access modes of bzr were used<br>
<ul>
<li><a class="moz-txt-link-freetext" href="file://">file://</a> where
the files are accessed through the local machine's
mounts - NFS or a physical local disk</li>
<li>bzr:// where the files are accessed through a network socket and
a "bzr serve" runs supplying a repository that is positioned on the
server machine (cms01), located either on
a NFS disk or a local disk.</li>
</ul>
All tests were run using a repository with 3482 revisions and 3970
working tree files totalling 85Mb. bzr info says this about the repos:<br>
<br>
<tt>Repository tree (format: dirstate-tags)<br>
Location:<br>
shared repository: /data/id/CmsRoot/repos/CVTOOL<br>
repository branch: .<br>
</tt><br>
and bzr has this to say about itself:<br>
<br>
<tt>Bazaar (bzr) 1.5<br>
Python interpreter: /usr/bin/python 2.5.1<br>
Python standard library: /usr/lib/python2.5<br>
bzrlib: /usr/lib/python2.5/site-packages/bzrlib<br>
</tt> <br>
The OS is Ubuntu Gutsy i386.<br>
<br>
The results are in (elapsed / CPU) seconds:<br>
<br>
<tt> source <a class="moz-txt-link-freetext" href="File://NFS">File://NFS</a>
<a class="moz-txt-link-freetext" href="file://local">file://local</a>
bzr://cms01/NFS bzr://cms01/local<br>
<br>
destination<br>
desk01 local 66 / 33 X 53 /
45 49 / 43<br>
desk01 NFS 662 / 59 X 702 /
61 507 / 58<br>
<br>
cms01 local 72 / 56 36 / 35 104 /
74 62 / 55<br>
cms01 NFS 497 / 40 187 / 48 1225 /
84 1045 / 73<br>
</tt><br>
A simple copy of the repository (including the .bzr directory) from NFS
to a local disk on desk01 takes 3.1 seconds and NFS to NFS takes 84
seconds at a low-load time of day. Clearly there is significant room
for improvement in bzr when you compare the closest bzr equivalents to
this copy (36 and 187 seconds). From an admittedly very naive
perspective, the branch bzr makes is only a copy of the repos (when
branch is used without options).<br>
<br>
The time shown for each test is the best seen of the few runs I did.
Especially with the NFS to NFS tests I saw huge variations (e.g. from
13 minutes to 38 minutes for one test). The tests show:<br>
<br>
<ol>
<li>Using an NFS server for the location of your local branch is not
a good idea. I've also seen the same problem when building the project.
This problem gets seriously worse during high-load times when
everyone on the network is trying to do things in their NFS mounted
home file systems. The
differences between desk01 and cms01 when using NFS as the
destination are probably partly due to the load variations. I have seen
no specific bzr connection with this problem.</li>
<li>The <a class="moz-txt-link-freetext" href="file://NFS">file://NFS</a>
to local times are reasonable, but are still susceptible
to load issues, and worse still contribute to those load problems.</li>
<li><a class="moz-txt-link-freetext" href="File://">File://</a> is better than bzr:// when using a local destination.
Surprisingly bzr:// across the network was quicker than bzr:// used on
the same machine.<br>
</li>
</ol>
I am no expert with NFS and cannot tell if our NFS server has been
configured optimally; our IT boys say they've checked it all. Further I
do not know if the dirstate-tags repository format is a good choice. It
was the default when the repos was made in January this year. I find
the information in the manuals very uninformative regarding the
benefits of the various formats that are listed in (e.g.) the reference
for the upgrade command.<br>
</body>
</html>