subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Shahaf" <...@daniel.shahaf.name>
Subject Re: SVN and webdav
Date Mon, 05 Oct 2020 17:55:19 GMT
Marek Manukjan wrote on Mon, 05 Oct 2020 10:00 +00:00:
> I'm not an expert on SVN's HTTP protocol so I don't know if there is 
> another variant of the Commit command like there are two modes of 
> Update, but from apache's access log it seems that Commit is done as 
> one initial POST request, then each file is uploaded as separate PUT 
> request, and the operation is finalized with MERGE request. Someone 
> else might want to confirm/disprove this, as it's based purely on 
> observation of the access log, not in-depth knowledge.

This is how commits are performed over http when the client and server
are both sufficiently new.  There _is_ another way to perform commits
over http, used when either the client or server is older.  grep the
source for for "create-txn".

Cheers,

Daniel

> To clear up the difference between using SVNAllowBulkUpdates and 
> KeepAlive, as they control separate things:
>  * SVNAllowBulkUpdates controls how many HTTP *requests will be done in 
> total* for Checkout/Update/Switch operation. It doesn't affect Commit, 
> as it seems it always uses multiple requests
>  * KeepAlive controls how many HTTP *requests will be done per one TCP 
> connection* for any operation
> From your initial question I can't quite make out which of the two you 
> want to actually control (not familiar with haproxy), but both should 
> be achievable using these configuration attributes.
> 
> On Mon, Oct 5, 2020 at 10:49 AM Wokash Wolsku <wokashwolski@outlook.com> wrote:
> > This is helpful, thank you, however, reading the links especially SVNAllowBulkUpdates
talks of getting the tree.  What directives control updates to the tree.  The situation I
face is that some clients have to up load large graphics files, and video, these will be one
object and presumably report request, on first reading that does not appear to be covered
by the SVNAllowBulkUpdates.
> > 
> > The KeepAlive seem also a corse way to achieve this...
> > 
> > Thanks again.
> > *From:* Marek Manukjan <marek.manukjan@bisimulations.com>
> > *Sent:* 05 October 2020 10:24
> > *To:* Wokash Wolsku <wokashwolski@outlook.com>
> > *Cc:* users@subversion.apache.org <users@subversion.apache.org>
> > *Subject:* Re: SVN and webdav 
> >  
> > It depends on server and client configuration. See following configuration attributes

> >  * SVNAllowBulkUpdates (On, Off, Prefer)
> >    * Bulk update means that all files will be received in a single REPORT request
> >    * Non-bulk (Skelta) mode, used by default in newer clients, means that each file
will use its own GET request
> >    * see https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
> >    * see http://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html
> >  * standard Apache configuration attributes KeepAlive, KeepAliveTimeout, MaxKeepAliveRequests
> >    * they control how many HTTP requests can be done in a single connection to server
> >    * https://httpd.apache.org/docs/2.4/mod/core.html#keepalive
> > 
> > On Mon, Oct 5, 2020 at 10:10 AM Wokash Wolsku <wokashwolski@outlook.com> wrote:
> >> I am trying to use haproxy to rate control some svn clients which access the
SVN repro via svn+https.  Some monitoring has thrown up some questions.
> >> 
> >>  1.   When for example doing a checkout or commit of a large number of files
is this implemented as 
> >>    1. 1 https request or many
> >>    2. 1 web dav action or many?
> >>  2. from the logs of haproxy (and I am by no means an expert) I see only one
connect and one https request.
> >> I was hopping to rate limit the clients by IP address and thereafter http requests
hence to slow down large users so others get a share of the processor.  But without the volume
of up load being related to http requests I am struggling to see how to implement this.
> >> 
> >> Can anyone offer any advise.
> >> 
> >> Wocash

Mime
View raw message