AW: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
From: Markus Schaber <m.schaber_at_codesys.com>
Date: Mon, 3 Dec 2012 09:43:18 +0000
Just another crazy idea:
The main problem with the parallelization in ra_serf seems to be the number of http requests (which potentially causes a high number of authentications and tcp connections).
Maybe we could add some partitioned send-all request:
When the client decides to use 4 connections, it could send 4 requests, with some parameter like send-all(1/4), send-all(2/4), ..., send-all(4/4).
Then the server can send one quarter of the complete response on each connection.
An advanced server could even share the common state of those 4 requests through some shared memory / caching scheme, to avoid doing the same work multiple times.
Years ago, I implemented a similar scheme between caching GIS web frontend servers, and the rendering backend server, in the protocol for fetching and rendering the map tiles. It gave a nearly linear speedup with the number of connections, up to the point where the CPUs were saturated.
CODESYSŪ a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
E-Mail: m.schaber_at_codesys.com | Web: codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
On Sat, Dec 1, 2012 at 9:01 AM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
I'm specifically thinking of the use Kerberos per request
And the same is true for https connections, where it's also the server
Totally agreed. I'd favor a three-value httpd directive option on the server-side that is advertised in the capabilities exchange:
- default (client defaults to parallel if ra_serf, serial if older ra_neon client; or if client overrides ra_serf via their local servers options)
I'm 95% sure we have code in ra_serf that handles the case where the server sends us inline responses anyway as older (prior to 1.2, IIRC) always sent inline responses no matter what we send...so, it should be fairly straightforward decision tree with minimal code changes.
My $.02...which is still not enough for me to write the patch. =) -- justin
This is an archived mail posted to the Subversion Dev mailing list.