send-all='true' update REPORT mode and ra_serf

[Ivan Zhakov <iv...@visualsvn.com>]

Hi,

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?

-- 
Ivan Zhakov

Re: send-all='true' update REPORT mode and ra_serf

[Mark Phippard <ma...@gmail.com>]

2011/2/17 Branko Čibej <br...@e-reka.si>:
> On 17.02.2011 21:43, Mark Phippard wrote:
>> On Thu, Feb 17, 2011 at 3:35 PM, Ivan Zhakov <iv...@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/

Re: send-all='true' update REPORT mode and ra_serf

[Branko Čibej <br...@e-reka.si>]

On 17.02.2011 21:43, Mark Phippard wrote:
> On Thu, Feb 17, 2011 at 3:35 PM, Ivan Zhakov <iv...@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.

-- Brane

Re: send-all='true' update REPORT mode and ra_serf

[Mark Phippard <ma...@gmail.com>]

On Thu, Feb 17, 2011 at 3:35 PM, Ivan Zhakov <iv...@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.

We also have the SVNAllowBulkUpdates directive that we could let a
server admin use if they wanted the clients to use GET's because they
had a working proxy.

http://subversion.tigris.org/issues/show_bug.cgi?id=3121

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/