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

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

From: Lieven Govaerts <lgo_at_apache.org>
Date: Tue, 9 Jul 2013 10:09:34 +0200

On Tue, Jul 9, 2013 at 9:55 AM, Ben Reser <ben_at_reser.org> wrote:
[..]
> Have we considered just turning off chunked requests entirely until
> Serf has a fix to automatically detect and handle servers that don't
> support chunked requests?

Note, again: Serf will not have a feature to automatically detect that
servers don't support chunked requests. Such a check is implemented in
ra_serf with the extra OPTIONS request, there's no other way to do
this without the extra roundtrip.

What Serf 1.4 will have is a way to calculate the length of buckets
without overhead, so that ra_serf can then add the Content-Length
header to each request.

> I've seen a lot of discussion about the
> cost of doing an extra round trip to detect if we can use chunked
> encoding, but I haven't seen anyone comparing the performance of the
> client with and without chunked requests.

The cost of setting the Content-Length header on each request at this
time (serf 1.2.1/serf 1.3), is that each request will be read
completely in memory (a second copy of the request in memory) or
spooled to disk for requests larger than 32MB. See setup_serf_req in
ra_serf/util.c.
If a request body was already persisted to disk first (e.g. commit),
it will also follow the same procedure.

I haven't measured the effect of all this, but you see that there's an
overhead involved.

Serf 1.4 will solve this because then ra_serf can ask the request body
bucket for its complete length without needing to read the whole
bucket completely first.

Lieven
Received on 2013-07-09 10:10:35 CEST

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

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