Were these "recently added" changes #1 and #2 added in to subversion
release 0.24.2, or 0.25.0?
-RG
On Friday, Jul 11, 2003, at 15:26 America/Chicago, Ben Collins-Sussman
wrote:
> "Clint Chapman" <clint@luminosindustries.com> writes:
>
>>> So this whole "three minute" thing that you're seeing, Philip, is
>>> basically net result (B) in change #1.
>>
>> Does this explain timeouts when committing a single large file?
>> I still seem to get the error described in issue 1350 with a single
>> 130MB
>> file.
>
> No, this sounds like a different bug.
> I'm talking about checkouts/updates. Your bug is about commits.
>
> Can you file it, if not filed already?
>
On Friday, Jul 11, 2003, at 15:06 America/Chicago, Ben Collins-Sussman
wrote:
> 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
>
>
---------------------------------------------------------------------
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:40:26 2003