On Wed, May 11, 2011 at 11:12 PM, Justin Erenkrantz <jus...@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) {