On Thu, Aug 30, 2012 at 4:56 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > On 08/30/2012 08:05 AM, C. Michael Pilato wrote: >> On 08/30/2012 06:10 AM, Justin Erenkrantz wrote: >>> On Wed, Aug 29, 2012 at 4:04 PM, C. Michael Pilato <cmpil...@collab.net> >>> wrote: >>>> I misremembered Greg and Justin's attitude toward my approach, thinking >>>> they >>>> were just flatly opposed. As I re-read the relevant threads, though, I >>>> think it's clear that perhaps both my approach and their PROPFIND-Depth-1 >>>> approach would be valuable. The problem, as I see it, is that the >>>> complexity of the PROPFIND-Depth-1 change is far greater than my simple >>>> patch, and nobody is stepping up to own it. >>> >>> Yes, I don't think it was that we were flatly opposed - it's that we >>> can figure out a way to reduce the number of requests even against >>> older servers - which is a good thing. But, let's not stand in the >>> way of progress if there is a new server. So, commit away! -- justin >> >> Thanks for clarifying. Before I commit away, though, it occurred to me last >> night that I've not done anything to profile the memory usage >> characteristics of this approach. I need to understand what happens if the >> REPORT response processing (and property queuing) vastly out-paces the GETs >> and such. > > I hacked my mod_dav_svn to add a sleep(1) before responding to each GET > request. Funny thing ... it made my checkouts against the localhost run > really slowly. ;-) > > Anyway, my point was to see if there would be a memory usage difference > between today's ra_serf -- which fetches properties for a node immediately > before GETting the content for that node -- and my patched one, which I > imagine would long have finished parsing the REPORT and caching all the > properties therein before even half of the GETs were completed. I > definitely saw different behaviors in terms of the rate at which peak memory > usage was hit, but the peak memory footprint looked about the same in both > cases. > > Theoretically, though, it seems reasonable that my approach would have the > distinct non-feature of potentially having the client caching the properties > for an entire tree in memory, just waiting for a place to put them. It should not happen in current ra_serf editor implementation: parsing REPORT will be paused when active_fetchs + active_propfinds greater than 1000. See REQUEST_COUNT_TO_PAUSE/REQUEST_COUNT_TO_RESUME constants in libsvn_ra_serf/update.c
-- Ivan Zhakov
