Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: Expected speed of commit over HTTP?
To: dev@subversion.apache.org
References: <CA+298UjBKUx4fojNwUWbeFSSSuWT+fqo0rZyLtzt-NWkGCZHhA@mail.gmail.com>
From: =?UTF-8?Q?Branko_=c4=8cibej?= <brane@apache.org>
Organization: The Apache Software Foundation
Message-ID: <b40297eb-24c4-df5d-d7e2-930b13130150@apache.org>
Date: Thu, 6 Jul 2017 14:03:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CA+298UjBKUx4fojNwUWbeFSSSuWT+fqo0rZyLtzt-NWkGCZHhA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
archived-at: Thu, 06 Jul 2017 12:03:53 -0000

On 06.07.2017 13:54, Paul Hammant wrote:
> For something that's 500MB in size (random binary data) I'm
> experiencing commits taking 
> 10x longer than a straight copy to the drive the Svn repo is on.  
>
> Both timings are on the same Ubuntu 17.04 machine, with the boot drive
> being the starting position of the 512MB file and a USB3 mounted 4TB
> seagate hard drive being the destination.
>
> My goal is to fill the 4TB drive with commits for the simple
> experience of that.
>
> How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff
> does the 512MB temporarily manifest itself in a file system on the way
> to its ultimate destination?  Is 1/10th speed the expectation?  Sure,
> I get that 7bit/8bit shenanigans are a factor, but not that much right?

7 vs. 8bit shouldn't be an issue; data transfers are binary. If you're
committing updates to the file, deltification could be part of the
reason for the slowdown. Other than that ... performance measurements
would help.

-- Brane