On Tue, May 8, 2012 at 2:49 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On 05/08/2012 02:34 PM, Mark Phippard wrote:
>>> Now that I can run the test I wanted, the performance improvement is
>>> pretty nice. Checking out our code goes from 1m35s down to 0m44s. I
>>> cannot help but think that number should still be a lot lower though.
>>> This scenario seems like it would be very similar to what a Git
>>> checkout would do now, probably even less work has to be done. I do
>>> not have a Git-svn version of our codebase to test with, but I am
>>> guessing a Git checkout of our code would be less than 10 seconds. So
>>> it might be an indication we could be doing more optimization in our
>>> libraries.
>>>
>>> That said, I still think it is a nice improvement and I imagine it
>>> would scale up and down based on size and number of files.
>>>
>>> Does anyone have a git version of our tree they could try this with?
>>> How long does it take git to materialize a working copy of our trunk?
>>
>> As I said before, I suspect your numbers would be much lower if I wasn't
>> sending HEAD requests for each file. Unfortunately, ra_serf is depending on
>> the ordering of the pipelined requests (PROPFIND results for a given path
>> must be processed before the contents of the file are fetched), and I don't
>> know how to make that happen without ripping apart the pipelining machinery
>> and doing something custom there.
>
> Now that it works for me, I will try it some more with my own server
> so I can check the logs. When I was trying this before, it seemed
> like all of the HEAD requests were sent in the first second (which I
> thought was also producing the open files problem?). So I am
> operating under the theory that we are still kind of slow in
> installing the file from our pristine store.
>
> I assume that if I have a 44 second checkout, then I should see HEAD
> requests in the server logs happening during most of that 44 seconds
> if that is contributing to the problem?
Yup. But at a guess, I think we're slower than Git simply because we
do more work. Once the pipe is stuffed full of requests, there really
aren't any gaps/pauses that will occur. I think you'll see an even
spread of HEAD requests. They will just be "in between" other stuff,
without contributing measurably to the overall process duration. (ie.
they control the flow, rather than spend time)
Cheers,
-g
Received on 2012-05-08 20:55:47 CEST