On Wed, Jul 10, 2013 at 9:57 PM, Greg Stein <gst...@gmail.com> wrote: > On Wed, Jul 10, 2013 at 6:57 PM, Ben Reser <b...@reser.org> wrote: >> 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 >> domain name. > > Human perception is right around the 250ms mark. User interface > designers use that metric for response time.
[...] > In any case. In your example, with a 160ms latency, then RTT*2 is past > that barrier. The user will notice a lag. > > That said: there may already be other lag, so RTT*2 might be 320ms of > a 5s response time. I'd say that there absolutely is other lag in all of these cases. If we were always responding under the 250ms mark that you point out above (and that I agree with), then I'd be a lot more concerned about this change. However, every one of these cases results in a lot more delay that that. I guess I could have measured that and measured how long the delay was for the first result. But I'm pretty confident in saying this change doesn't push us past a 250ms delay we're not already past. Consider that the log --diff example I gave. It used 91 requests, 11 of which were extra OPTION request to detect chunking, in order to provide the log and diff of 5 revisions. It used 11 sessions and 22 connections to do so. Even without this patch log --diff noticeably pauses on each log entry to retrieve the diff, well past a 250ms delay when I'm using it against svn.us.apache.org which I have around 20ms latency to. On another front I ran our test suite and timed it in several configurations (this is with the tristate branch and its option meanings): auto(through nginx 1.2.9) real 30m41.060s user 15m14.803s sys 12m34.307s no(through nginx 1.2.9) real 30m50.127s user 15m16.974s sys 12m37.019s yes(direct) real 30m23.280s user 15m13.347s sys 12m27.483s auto(direct) real 30m35.522s user 15m15.198s sys 12m29.660s no(direct) real 30m22.735s user 15m14.443s sys 12m30.666s Obviously latency is almost a non-issue here because everything is local (<1ms) so what I'm really looking to show is the relative performance of CL vs Chunked requests. I didn't repeat these tests, so you're seeing a single result. So there may be some variation between test runs that isn't averaged out. As you can see though there is very little difference in these test as far as time. The biggest difference is 23 seconds, which is just slightly more than 1% performance degrediction between yes(direct) and no(through nginx 1.2.9) and at least some of that comes from nginx being in line. Now part of the concern over CL is that we'd end up having to use temp files. My test setup was using ramdisk for the test workspace and the system disk is a SSD, so that might help hide some of that. Even more importantly I believe the request needs to be over 100k before it'd need a tempfile, so I kinda doubt our test suite exercises that much. But so far I'm not seeing any major performance penalty in using CL instead of chunked requests. Obviously in the future that may become more significant.
