[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN and webdav

From: Marek Manukjan <marek.manukjan_at_bisimulations.com>
Date: Mon, 5 Oct 2020 10:24:56 +0200

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_at_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
>
Received on 2020-10-05 10:25:13 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.