On Thu, May 24, 2012 at 1:29 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Thu, May 24, 2012 at 12:33:08PM -0700, Shawn O. Pearce wrote:
>
>> $ (for i in {1..5}; do time git ls-remote
>> persistent-https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
>> >/dev/null;done) 2>&1 | grep real
>> real 0m0.208s
>> real 0m0.085s
>> real 0m0.079s
>> real 0m0.067s
>> real 0m0.059s
>
> Nice numbers. And as clever as I find this helper-wrapping-a-helper
> solution, I wonder if the right layer for a fix isn't inside curl. It
> already keeps an ssl session-id cache in memory; how hard would it be to
> turn that into an on-disk cache?
>
> I don't think that is grounds for rejecting this patch; obviously it is
> working for you guys, and it is available right now, and it is only
> going into contrib/ anyway. But a curl solution seems like a cleaner
> long-term fix, and would benefit all curl users. It is even mentioned in
> curl's doc/TODO file. :)
Well, this helper "solution" also has the benefit of HTTP keep-alive
working across Git command invocations. Its common for servers to use
a 5 minute keep-alive on an HTTP 1.1 connection. Git-over-HTTP
commonly uses Transfer-Encoding: chunked on replies, so keep-alive
will generally just work, even though a pack stream's length isn't
known in advance. Because the helper is an external process holding
that connection open, we also benefit from being able to reuse an
existing TCP connection to the server.
But sure, it would be nice if libcurl was able to share SSL sessions
across Git command invocations without this black magic proxy thing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html