[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal: new fsfs.conf properties

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 14 Jul 2017 16:53:56 +0200

On Fri, Jul 14, 2017 at 4:31 PM, Evgeny Kotkov
<evgeny.kotkov_at_visualsvn.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>
>> Nice!
>>
>> But how about deltification? Has anyone tried / benchmarked the effect
>> of turning off deltification (with or without compression), to see
>> what the effect would be on the commit time? Like I suggested in this
>> thread yesterday (i.e. set max-deltification-walk to 0 in fsfs.conf --
>> or perhaps play with both max-deltification-walk and
>> max-linear-deltification) ...
>
> I haven't tested commit with deltification enabled/disabled in config, but
> a synthetic benchmark of the deltification itself (create two big random
> files, run vdelta-test -q over them) shows a rate of around 340-350 MiB/s
> on my machine.
>
> That's probably enough to not slow down commits in an immediately visible way.

That's good to know. Though that's a bit at odds with what Philip
found when he eliminated deltification on the client side (first by
using svnmucc (delta against empty file only); then by using curl-PUT
+ autoversioning (no deltification at all)):

https://svn.haxx.se/dev/archive-2017-07/0040.shtml

Is it slower / more intensive to deltify on the client side?

-- 
Johan
Received on 2017-07-14 16:54:24 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.