Re: svn commit: r1388202 - in /subversion/branches/10Gb/subversion: include/svn_ra_svn.h libsvn_ra_svn/client.c libsvn_ra_svn/marshal.c libsvn_ra_svn/ra_svn.h svnserve/main.c svnserve/serve.c svnserve/server.h

On Thu, Sep 20, 2012 at 08:34:52PM -0000, stefan2_at_apache.org wrote:
> Author: stefan2
> Date: Thu Sep 20 20:34:52 2012
> New Revision: 1388202
>
> URL: http://svn.apache.org/viewvc?rev=1388202&view=rev
> Log:
> On 10Gb branch: Add --zero-copy-limit parameter to svnserve and pass
> it down to the reporter.

Should we really expose a switch like that at the UI?

The description you give is:

> @@ -235,6 +236,16 @@ static const apr_getopt_option_t svnserv
> "Default is no.\n"
> " "
> "[used for FSFS repositories only]")},
> + {"zero-copy-limit", SVNSERVE_OPT_ZERO_COPY_LIMIT, 1,
> + N_("send files smaller than this directly from the\n"
> + " "
> + "caches to the network stack.\n"
> + " "
> + "Consult the documentation before activating this.\n"
> + " "
> + "Default is 0 (optimization disabled).\n"
> + " "
> + "[used for FSFS repositories only]")},

Which to me looks like a scary flag I'd rather leave alone. :)

Can't we use some heuristic to determine whether or not to enable
this optimisation, so the user won't have to reason about whether
or not to use this option? Is designing the heuristic just a matter
of finding a good threshold by experimentation on sample data sets?
Received on 2012-09-20 23:38:18 CEST