RE: Large Repositories - related to Re: Issuezilla #1350 -- update

I took this to mean that I no longer needed to override the default
timeout, and tried it without http-timeout = 600, but no such luck:

>time svn co $SVN/trunk/webcenter/prod/htdocs
subversion/libsvn_ra_dav/util.c:411: (apr_err=175002)
svn: RA layer request failed
svn: REPORT request failed on '/svn/repos/!svn/vcc/default'
subversion/libsvn_ra_dav/util.c:81: (apr_err=175002)
svn: REPORT of '/svn/repos/!svn/vcc/default': timed out waiting for
server ([URL deleted])

real 2m2.512s
user 0m0.053s
sys 0m0.023s

Should this still be happening? This is httpd 2.0.47 and a revision
from today of svn.

--
Graham Johnson
gjohnson@alpineaccess.com
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net] 
Sent: Friday, July 11, 2003 2:06 PM
To: Johnson, Graham
Cc: Russell Glaue; dev@subversion.tigris.org
Subject: Re: Large Repositories - related to Re: Issuezilla #1350 --
update
Ben Collins-Sussman <sussman@collab.net> writes:
> Maybe that's the real problem here... can the client really take 3 
> minutes just to parse 1000 of those <response> objects?  I mean, 
> neither client nor server is "blocking" on the other, as they used to 
> be, but still this system isn't optimal.  :-(
Ah, now I understand what's going on here, after chatting with Sander in
IRC.
There are two changes that happened recentl, to make checkouts "better".
* Change #1:  fewer network turnarounds.
  In the bad old days, our checkouts/updates looked like this:
    The client parses the REPORT response -->
      For each file,
        PROPFIND, GET
        PROPFIND, GET
        PROPFIND, GET
        [...]
  In the good new days, the algorithm is:
    The client parses the REPORT response -->
      For each file,
        PROPFIND depth 1, cache all file proplists
        look in cache, GET
        look in cache, GET
        look in cache, GET
        [...]
  Net result: (A) fewer network requests, and thus faster "overall"
  times for checkouts/updates.  (B) slower perceived startup time,
  since the GETs start happening later.
* Change #2:  streamy server PROPFIND response
  In the bad old days, the PROPFIND depth 1 response would cause
  mod_dav to build the list in memory, then send it to the client all
  at once.  This often caused the client to time out, assuming it took
  X seconds for server to generate the list, and X > neon_timeout_val.
  In the good new days, the server streams the response.  But
  generating the response *still* takes X seconds.  Neon is no longer
  timing out, but it still takes X seconds before the client finishes
  receiving the whole response and starts doing GET requests.
  Net result:  no more neon timeouts on large directories.
So this whole "three minute" thing that you're seeing, Philip, is
basically net result (B) in change #1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org