Another interesting point comes from Julian’s earlier tests: Adding compressing
(mod_deflate?) increases the buffer space on the server side, thereby adding
additional time.
(I usually disable this in my test environments for easier diagnostics)
Bert
From: Stefan Fuhrmann [mailto:[email protected]]
Sent: woensdag 15 april 2015 21:27
To: Evgeny Kotkov
Cc: Subversion Development
Subject: Re: svn commit: r1673919 - /subversion/branches/1.9.x/STATUS
On Wed, Apr 15, 2015 at 8:19 PM, Evgeny Kotkov <[email protected]
<mailto:[email protected]> > wrote:
Evgeny Kotkov <[email protected] <mailto:[email protected]> > writes:
> + -0.5: kotkov (could not reproduce the improvement with a real-world 1.9
> + server; see my e-mail to <[email protected]
> <mailto:[email protected]> >)
I regret to say that I failed to reproduce the improvement with a deployed
server and a couple of real-world repositories.
After setting up a D-series Microsoft Azure virtual machine [1] with
Apache 2.2.29, Subversion 1.9.x and simplest httpd.conf content, I tried to
reproduce the lag by just running 'svn log' for both http:// URIs and working
copies. I couldn't tell the difference by eye, so, I cooked up a dirty patch
for the command-line client that measures the time between svn_client_log5()
call and the print call for the first log entry.
Then, I repeated my tests against the patched and the non-patched 1.9.x
servers. The results are attached, and they do not show any noticeable
difference. Does anybody have a strict reproduction script with a 1.9.x
server that shows the practical benefit from this patch?
Hi Evgeny,
Thanks for the feedback anyway!
I think you could see a difference for the bsd repo
if you run the log for the /head (which is their trunk)
folder. Via ra_local, I get 2 min (cold) or 9s (2nd run)
for /head but .3s for the root (cold and hot).
Basically, there is special code that makes log for "/"
just enumerate the revisions. And if you don't fetch
revprops or do authz, the send buffers get filled
immediately.
-- Stefan^2.
