On Wed, May 11, 2011 at 11:12 PM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> r1102173 will help slightly when there are lots of checkouts as
This patch will also halve the amount of data that ra_serf retrieves
for the basic benchmark test (28MB down to 13MB on the wire)...but,
what's rather odd is that the svndiff1/svndiff stuff never seems to
kick in on an update. So, mod_dav_svn just ends up always sending the
plain text...which is kinda silly as gzip would be far better than
plain-text (especially in this dataset). So, this tells httpd that it
can send along gzip responses...and we get reasonable compression.
However, I think there's an underlying bug in that we're not sending
svndiff1 back at all; and I have a hunch that the content negotiation
algorithms aren't actually implemented across modules. But, it'd be
completely legitimate for ra_serf to send it...it's just...well...I
suspect that if mod_dav_svn were to send svndiff1, it'd do svndiff1 +
gzip...which isn't good. So, someone should go bug-hunting for why
we're not sending svndiff1 responses... -- justin
Index: subversion/libsvn_ra_serf/update.c
===================================================================
--- subversion/libsvn_ra_serf/update.c (revision 1102178)
+++ subversion/libsvn_ra_serf/update.c (working copy)
@@ -679,8 +679,16 @@ headers_fetch(serf_bucket_t *headers,
{
serf_bucket_headers_setn(headers, SVN_DAV_DELTA_BASE_HEADER,
fetch_ctx->info->delta_base->data);
- serf_bucket_headers_setn(headers, "Accept-Encoding",
- "svndiff1;q=0.9,svndiff;q=0.8");
+ if (fetch_ctx->conn->using_compression)
+ {
+ serf_bucket_headers_setn(headers, "Accept-Encoding",
+ "svndiff1;q=0.9,svndiff;q=0.8,gzip;q=0.7");
+ }
+ else
+ {
+ serf_bucket_headers_setn(headers, "Accept-Encoding",
+ "svndiff1;q=0.9,svndiff;q=0.8");
+ }
}
else if (fetch_ctx->conn->using_compression)
{
Received on 2011-05-12 10:10:14 CEST