Re: Proposal: new fsfs.conf properties

Johan Corveleyn <jcorvel_at_gmail.com> writes:

> As I said in my previous response here, I think the reason for Paul to
> go for curl+autoversioning is speed, because it eliminates client-side
> deltification. It was suggested and demonstrated by Philip here:

Using a trunk build, I'm uploading 500MB urandom files:

  dd if=/dev/urandom bs=1M count=500 > u1.dat
  dd if=/dev/urandom bs=1M count=500 > u2.dat
  dd if=/dev/urandom bs=1M count=500 > u3.dat

using

  curl -T u1.dat http://localhost/repo/curl.dat
  curl -T u2.dat http://localhost/repo/curl.dat
  curl -T u3.dat http://localhost/repo/curl.dat

and

  svnmucc -mm put u1.dat http://localhost/repo/svn.dat
  svnmucc -mm put u2.dat http://localhost/repo/svn.dat
  svnmucc -mm put u3.dat http://localhost/repo/svn.dat

to a repository with compression-level=0 and enable-rep-sharing=false.

The upload that creates the file is faster than the upload that updates
the file:

           curl create time: 4.2s
           curl update time: 6.7s
     curl CPU in both cases: 0.2s

        svnmucc create time: 5.2s
        svnmucc update time: 7.7s
  svnmucc CPU in both cases: 1.2s

The difference between curl and svnmucc matches the extra CPU used by
svnmucc.

The difference between create and replace is due to the extra server CPU

      httpd CPU create: 3.0s
     httpd CPU replace: 5.5s

The fact that the create is faster than the update means that if
uploading the data is the only thing that matters then breaking the
history and changing the update into a delete+recreate is faster, i.e.

  svnmucc -mm -U http://localhost/repo put u1.dat svn.dat
  svnmucc -mm -U http://localhost/repo rm svn.dat put u2.dat svn.dat
  svnmucc -mm -U http://localhost/repo rm svn.dat put u3.dat svn.dat

The delete+recreate takes the same 5.2s as the original create and is
faster than curl's 6.7s update.

-- 
Philip