On Wed, Jul 10, 2013 at 7:45 AM, Greg Stein <gstein_at_gmail.com> wrote:
> IOW, while I may agree with "regression", I'm not sure that we should
> impact 99+% in order to deal with it. I'm not sure it is a reasonable
Providing some real world numbers.
I tested against: http://svn.mkgmap.org.uk/mkgmap/trunk
Which is known to have a proxy in front of it that rejects chunked requests.
While I tested against a server that has the problem I don't expect
the difference between real world performance of those with or without
the issue to differ, I expect the response to the second OPTIONS
request to be about the same regardless. Doing it against a busted
server made it a little easier because I could just count the 411s.
I have about 160ms of latency to this server. Mostly because I'm on
the west coast of the US and it's in the UK someplace based on it's
I didn't bother to figure out what version of SVN this server is
running, but that would impact this because of the various changes
we've made to our protocol over time.
I'll present the results here in RTT*number of times we made an extra
CHECKOUT: RTT*2 [didn't bother to test export, assume it's the same as checkout]
LOG --diff: RTT*(1+(revisions*2) [It appears we make 2 connections
per revision to do the diff, ouch, I guess that explains why log
--diff is so slow already]
MERGE -c 2652 ^/branches/options2: RTT*2 [several files]
MERGE -c 2498 ^/branches/options2 RTT*2 [fewer files, I'm guessing
there's something that will make merge use more but I'm not sure what]
UPDATE: RTT*1 [didn't bother to test switch I'm assuming it's the same
BLAME: RTT*N [where N is the number of files being blamed, not that I
think people usually blame more than one file in a go]
LS ^/branches/options2: RTT*1
MERGEINFO ^/branches/options2: RTT*6 [no idea why this is so high I
STATUS -u: RTT*2
I obviously don't have write access to this server so I didn't test
anything that required write access.
Hopefully this gives everyone some real world info
Received on 2013-07-11 00:57:35 CEST