On 2/17/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> I'm not really sure how the whole pipelining thing works, but we (I)
> made fixes to Subversion's diff/merge code which caches the whole REPORT
> response to disk before processing it and doing the GET thang. I did
That's part of the problem I have - this is bad for the case where you
do not want full-texts. The client is sitting around waiting for a
response...Can we skip writing the REPORT response to disk if we're
not doing full-text?
> this because if a GET sent off in the middle of REPORT processing took
> too long to get fully handled, Apache dropped the connection on the
> REPORT (thinking "inactive client").
>
> We're not in the exact same scenario with ra_serf, but I'm wondering if
> we're not in something similar. What happens in the following scenario?
>
> c->s: REPORT request
> s->c: REPORT response
> # client starts parsing the REPORT response, and firing off GETs
> c->s: GET #1
> c->s: GET #2
> ...
> [more than httpd Timeout seconds goes by]
> c->s: GET #496
> ...
> # client finishes parsing REPORT, but that first GET long ago has
> # been sitting around unhandled for too long. Did Apache drop
> # that connection?
No. httpd's KeepAlive semantics are only about when the connection is
truly idle. TCP's Keep-Alive semantics will keep the connection open
as long as the client wants it to and httpd hasn't closed it down.
So, as soon as httpd is done with the REPORT response, it will then do
a read() on the socket - the new request is there for it to handle and
it will process up to 100 more requests before it closes the socket.
At that point, the client then has to re-queue up 101-496 (ra_serf
figures out that it should only queue up 101-200 at that point; as
before, each file is acquired through *two* HTTP requests - so halve
it). The change that I asked for in httpd's conf was that
svn.collab.net only allowed *10* HTTP requests per TCP connection.
Perhaps this'll help clarify what that change was actually about.
As I said in my earlier reply to Greg, mod_dav_svn takes *forever* to
write the update-report. There is an alternative to not using a
report (do a PROPFIND on each directory and walk the tree ourselves on
that client); but that would still likely be much much slower than
still doing the custom-report for this step. For an update where we
have some files locally, the update-report is by far the most best
solution as it lets the server know what we have and only tell us the
changed files. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 17 16:36:02 2006