[svnbook] r4333 committed - Finish issue 148 ("ch06: Give suggestions for tuning Apache to...
svnbook at googlecode.com
svnbook at googlecode.com
Fri Jan 18 09:43:56 CST 2013
Revision: 4333
Author: cmpilato at gmail.com
Date: Fri Jan 18 07:39:11 2013
Log: Finish issue 148 ("ch06: Give suggestions for tuning Apache to
maximize value of ra_serf").
* en/book/ch06-server-configuration.xml
(svn.serverconfig.httpd.perf): New section.
http://code.google.com/p/svnbook/source/detail?r=4333
Modified:
/trunk/en/book/ch06-server-configuration.xml
=======================================
--- /trunk/en/book/ch06-server-configuration.xml Wed Aug 29 00:16:41 2012
+++ /trunk/en/book/ch06-server-configuration.xml Fri Jan 18 07:39:11 2013
@@ -2574,6 +2574,128 @@
</sect3>
</sect2>
+ <!-- ===============================================================
-->
+ <sect2 id="svn.serverconfig.httpd.perf">
+ <title>Tuning for Performance</title>
+
+ <para>The Apache HTTP Server is built for performance, but you
+ can improve upon its default configuration to get even better
+ results out of your Subversion service offering. In this
+ section, we'll recommend some specific configuration changes
+ to consider. Understand, however, that some of
+ the <filename>httpd.conf</filename> configuration options
+ we'll be discussing herein affect the general behavior of your
+ server, not merely the Subversion service. As such, you need
+ to consider the full breadth of your HTTP service offering to
+ discern how modifications to these settings for Subversion's
+ sake may affect your other services.</para>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
+ <sect3 id="svn.serverconfig.httpd.perf.keepalive">
+ <title>KeepAlive</title>
+
+ <para>By default, the Apache HTTP Server is configured to
+ enable the re-use of a single server connection for multiple
+ requests. That's very beneficial for Subversion, because
+ unlike many HTTP-based applications, Subversion can very
+ quickly generate hundreds or thousands of requests against
+ the server for a single operation, and the cost of opening a
+ new connection to the server is non-trivial. Subversion
+ wants to squeeze as many requests as possible out of a
+ single connection before that connection is terminated by
+ the server. The <literal>KeepAlive</literal> directive is the
+ boolean flag which enables or disables this connection
+ re-use facility, and as we indicated previously, by default
+ its value is <literal>On</literal>.</para>
+
+ <para>But there's another directive which limits the number of
+ requests a client is allowed to submit on a single
+ connection: the <literal>MaxKeepAliveRequests</literal>
+ directive. The default value for that option
+ is <literal>100</literal>. This was probably sufficient for
+ older versions of Subversion, but Subversion 1.8 employs a
+ different HTTP communications library (called Serf) which
+ prefers to pipeline several smaller requests for specific bits
+ of information rather than asking the server to transmit
+ huge chunks of data in a single response. We recommend that
+ you increase the value of the
+ <literal>MaxKeepAliveRequests</literal> option
+ to at least <literal>1000</literal>.</para>
+
+ <informalexample>
+ <programlisting>
+#
+# KeepAlive: Whether or not to allow persistent connections (more than
+# one request per connection). Set to "Off" to deactivate.
+#
+KeepAlive On
+
+#
+# MaxKeepAliveRequests: The maximum number of requests to allow
+# during a persistent connection. Set to 0 to allow an unlimited amount.
+# We recommend you leave this number high, for maximum performance.
+#
+MaxKeepAliveRequests 1000
+</programlisting>
+ </informalexample>
+ </sect3>
+
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
+ <sect3 id="svn.serverconfig.httpd.perf.bulk-updates">
+ <title>Bulk updates</title>
+
+ <para>The biggest difference between the way that Subversion
+ 1.8 clients and pre-1.8 clients behave is in how update-style
+ operations (<command>svn checkout</command>, <command>svn
+ update</command>, <command>svn switch</command>, etc.) are
+ handled. Older clients which used the Neon HTTP library for
+ communications preferred to ask the server for the entire
+ payload of information required from the server in a single
+ request. Admins will have noticed that in their server
+ logs, there would be some initial handshaking operations,
+ and then a <literal>REPORT</literal> request with a massive
+ response. That response was the entire checkout/update
+ dataset!</para>
+
+ <para>Subversion clients which use the Serf HTTP
+ library—which includes all clients built atop the
+ Subversion 1.8—still send the <literal>REPORT</literal>
+ request, but with slightly different flags set inside that
+ request. These flags ask the server not to send all the
+ data for the operation, but to instead send only a checklist
+ of other more specific things that the client needs to
+ subsequently fetch from the server in order to complete that
+ operation. In the server's <filename>access_log</filename>,
+ that <literal>REPORT</literal> is followed by many smaller
+ requests (<literal>GET</literal>s and, in older versions of
+ Subversion, <literal>PROPFIND</literal>s).</para>
+
+ <para>There are pros and cons to each approach. As we've
+ mentioned, the so-called bulk updates generate considerably
+ less information in the server logs, but a given Apache HTTP
+ Server child process is completely consumed for the duration
+ of what could be a lengthy operation. Non-bulk updates
+ offer opportunities for setting up content caches (which
+ themselves can improve performance), but generate server log
+ traffic which is whole orders of magnitude larger than the
+ bulk update approach. So, for one reason or another,
+ administrators may desire to exert a little more control
+ over which approach the clients use. Subversion 1.6
+ introduced the <literal>SVNAllowBulkUpdates</literal>
+ <command>mod_dav_svn</command> directive—a simple
+ boolean flag—to allow admins to specify whether the
+ server was allowed to honor bulk update requests. In
+ Subversion 1.8, this directive has expanded to include
+ a <literal>Prefer</literal> value in addition to the
+ <literal>On</literal> and <literal>Off</literal> values it
+ already supported. When <literal>SVNAllowBulkUpdates</literal>
+ is set to <literal>Prefer</literal>, supporting clients (1.8
+ or newer) will try to use the bulk update approach unless
+ otherwise configured.</para>
+
+ </sect3>
+ </sect2>
+
<!-- ===============================================================
-->
<sect2 id="svn.serverconfig.httpd.extra">
<title>Extra Goodies</title>
More information about the svnbook-dev
mailing list