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
Received on Fri Jul 11 22:08:20 2003