On Wed, Dec 31, 2014 at 12:48 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> Any idea what causes this difference?
>
Yep, found it. The OS came with a 1.7.9 client.
Using a /trunk client, we are down to ~4min.
Most of that 3 min overhead seems to be HTTP processing
(the client CPU is much busier than against svnserve)
but I haven't actually measured it.
> Is it all in the security walk?
>
>
>
> The diff --summarize should result in a single report from server to
> client, without additional get requests for data
>
> (except for the one time ra session setup, revision lookup, etc. at the
> start)
>
Well, 1.7.9 seems to behave differently: 3..4min
of server-side processing with no output on the
client console, followed (slowly) sending data to
the client for display. No actual delta seems to
be transferred as the total amount of data is
about the same as with /trunk.
-- Stefan^2.
>
>
> *From:* Stefan Fuhrmann [mailto:stefan.fuhrmann_at_wandisco.com]
> *Sent:* woensdag 31 december 2014 00:11
> *To:* Evgeny Kotkov
> *Cc:* Stefan Fuhrman; Subversion Development
> *Subject:* Re: svn commit: r1648542 -
> /subversion/trunk/subversion/libsvn_fs_fs/tree.c
>
>
>
> On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov <
> evgeny.kotkov_at_visualsvn.com> wrote:
>
> Stefan Fuhrmann <stefan2_at_apache.org> writes:
>
> > URL: http://svn.apache.org/r1648542
> > Log:
> > In FSFS, remove the L1 DAG cache locking parameters.
>
> [...]
>
> As of this revision, I am also seeing random Apache HTTPD Server segfaults.
> I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542. I
> could
> not reproduce the crashes with the first build, but the second one *does*
> crash
> occasionally. Here is a sample backtrace:
>
>
> [...]
>
> Should be fixed with r1648612.
>
> Interesting observation: svnserve completes the test case in 1 minute
>
> while mod_dav_svn eats a whopping 30 CPU minutes. Everything with
>
> default settings on a format 7 repo with deltified directories.
>
>
>
> -- Stefan^2.
>
>
>
Received on 2015-01-02 12:44:37 CET