2011/2/17 Branko Čibej <brane_at_e-reka.si>:
> On 17.02.2011 21:43, Mark Phippard wrote:
>> On Thu, Feb 17, 2011 at 3:35 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>
>>> I'm looking to memory usage issues in svn update/export/switch in
>>> ra_serf. And I come to question: what is the rationale of using
>>> 'skelta' update REPORT mode, and then sending many GETs/PROPFINDs
>>> instead of using send-all='true' mode and receiving all deltas and
>>> properties in one response? Does it make sense to implement
>>> send-all='true' mode in ra_serf?
>> Wasn't the original idea that the GET requests could be served by a
>> HTTP proxy in front of the server? And also that running multiple
>> GET's at once would be faster?
>>
>> I do not think the proxy has turned out to be a reality and it does
>> not work with SSL, so maybe not a bad idea.
>
> Issuing multiple GETs in parallel will amortize the request latency over
> the number of parallel requests, and will typically also make better use
> of available bandwidth -- all of which makes ra_serf faster than
> ra_neon. Going back to a single huge request will not only throw away
> those benefits, it will also likely change the way a
> checkout/update/etc. can be resumed after a connection error.
*shrug*
I was just trying to answer Ivan who seems to see the current approach
as an explanation for the increased memory usage. If that is the
explanation maybe we should just write that down somewhere so we can
stop trying to make it use the same amount of memory as Neon?
In practice does checkout with Serf see the performance benefits you
predict? I have always used Neon because of the instability with
Serf.
Another benefit to the current Serf approach is that it is well suited
for some future version of SVN where we can leverage the new pristine
store to not download stuff we already have.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-02-18 01:35:36 CET