Some timings using bzr

[David Ingamells]

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:

    * files01 - the NFS file server. This was used both as a host
      location for the repository and as the destination for the branch.
    * 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)
    * desk01 used as a client using either the files01:NFS disk or a
      local disk

The files01 and cms01 are connected by a 1000 megabits per second link. 
desk01 has a 100 megabits per second link.

Two access modes of bzr were used

    * file:// where the files are accessed through the local machine's
      mounts - NFS or a physical local disk
    * 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.

All tests were run using a repository with 3482 revisions  and  3970 
working tree files totalling 85Mb. bzr info says this about the repos:

Repository tree (format: dirstate-tags)
Location:
  shared repository: /data/id/CmsRoot/repos/CVTOOL
  repository branch: .

and bzr has this to say about itself:

Bazaar (bzr) 1.5
  Python interpreter: /usr/bin/python 2.5.1
  Python standard library: /usr/lib/python2.5
  bzrlib: /usr/lib/python2.5/site-packages/bzrlib
 
The OS is Ubuntu Gutsy i386.

The results are in (elapsed / CPU) seconds:

         source  File://NFS     file://local    bzr://cms01/NFS    
bzr://cms01/local

destination
 desk01 local       66 / 33          X               53 / 
45               49 / 43
 desk01 NFS        662 / 59          X              702 / 
61              507 / 58

 cms01  local       72 / 56        36 / 35          104 / 
74               62 / 55
 cms01  NFS        497 / 40       187 / 48         1225 / 84             
1045 / 73

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).

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:

   1. 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.
   2. The file://NFS to local times are reasonable, but are still
      susceptible to load issues, and worse still contribute to those
      load problems.
   3. File:// is better than bzr:// when using a local destination.
      Surprisingly bzr:// across the network was quicker than bzr://
      used on the same machine.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080711/41d0c2a7/attachment.htm