[mirrorbrain-commits] r7763 - trunk/docs

Author: poeml
Date: Fri Aug 14 13:36:31 2009
New Revision: 7763
URL: http://svn.mirrorbrain.org/viewvc/mirrorbrain?view=revision&revision=7763

Log:
docs: beging writing the tuning guide, starting with Apache

Added:
   trunk/docs/tuning.rst
Modified:
   trunk/docs/index.rst

Modified: trunk/docs/index.rst
==============================================================================
--- trunk/docs/index.rst	Fri Aug 14 12:35:22 2009	(r7762)
+++ trunk/docs/index.rst	Fri Aug 14 13:36:31 2009	(r7763)
@@ -12,6 +12,7 @@
 
    intro
    installation/index
+   tuning
    configuration
    mirrors
    upgrading

Added: trunk/docs/tuning.rst
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ trunk/docs/tuning.rst	Fri Aug 14 13:36:31 2009	(r7763)
@@ -0,0 +1,117 @@
+.. _tuning:
+
+Tuning guide
+============
+
+The following sections describe how to tune PostgreSQL and Apache for good
+performance.
+
+Depending on the size of your install, this can be mandatory.
+
+
+Tuning Apache
+-------------
+
+MPM
+^^^
+
+In general, it makes sense to use a threaded MPM for Apache. Prefork is less
+suitable, because the database connection pool would not be shared across the
+worker children. With prefork, each process would open its own connection to
+the database. For small installations, this might not matter. However, for a
+busy download server, the threaded event MPM or worker MPM are better choices.
+
+The following would be a configuration for the event MPM which serves up to 960
+connections in parallel, using 64 threads per process. (Values for threads per
+process that scale best on Linux are 32 or 64.)::
+
+    # event MPM
+    <IfModule event.c>
+        ServerLimit           15
+        MaxClients           960
+    
+        StartServers           2
+    
+        ThreadsPerChild       64
+        ThreadLimit           64
+    
+        MinSpareThreads       32
+        # must be >= (MinSpareThreads + ThreadsPerChild)
+        MaxSpareThreads      112
+    
+        # at 200 r/s, 20000 r results in a process lifetime of 2 minutes
+        MaxRequestsPerChild 20000
+    </IfModule>
+
+
+DBD connection pool
+^^^^^^^^^^^^^^^^^^^
+
+With threaded MPMs, the database connection pool is shared among all threads of
+an Apache child. Thus, it makes sense to tune the size of the pool to the
+number of processes and threads. The following should fit the above Apache
+dimensions quite well::
+
+    DBDMin  0
+    DBDMax  12
+    DBDKeep 3
+    DBDExptime 10
+
+
+The total number of connections that Apache might open needs to be reflected in
+the PostgreSQL setup accordingly. The above example would be served safely with
+a database with a ``max_connections = 500`` setting. (This setting may seem far
+too high, but it keeps even enough headroom to start separate Apache servers
+for testing purposes, or for upgrade purposes (killing Apache with SIGWINCH for
+graceful stop, and starting a new one while the old one still continues to
+serve requests to their end).
+
+
+Thread stack size
+^^^^^^^^^^^^^^^^^
+
+When using lots of threads, their might be funny effects on some platforms. The
+default stack size allocated by the operating system for threads might be quite
+large, e.g. 8 MB on Linux. If this leads to problems, you could considerably
+decrease the stack size as such::
+
+    # If this isn't set, the OS' default will be used (8 MB)
+    # which is way more than necessary
+    ThreadStackSize 1048576
+
+But normally the default settings should just work, I guess.
+
+
+HTTP/1.1 KeepAlive
+^^^^^^^^^^^^^^^^^^
+
+KeepAlive, a HTTP/1.1 feature, saves overhead by reusing already existing TCP
+connections to process further HTTP requests. If no additional request arrives
+after n seconds, the server closes the connection.
+
+This is a good thing, but it can also become a problem when too many
+threads/processes linger around waiting for the next request in the connection.
+Each such thread would occupy a slot that could otherwise be used to handle
+other requests. In addition, even the number of unused ephemeral ports could
+become scarce under extreme conditions. The configured default of a KeepAlive
+time of 15 seconds in most Apache installs is far more than necessary. A good
+value is 2 seconds, which keeps the good side of KeepAlive, but avoids the
+drawbacks to the extent that they don't tend to be a problem.
+
+Hence, good settins are::
+
+    KeepAlive On
+    MaxKeepAliveRequests 100
+    KeepAliveTimeout 2
+
+
+.. Tuning PostgreSQL
+.. -----------------
+.. 
+.. To tune PostgreSQL for good performance, you should tweak the following
+.. parameters in :file:`postgresql.conf`.
+.. 
+.. 
+.. .. describe:: listen_addresses
+.. 
+..     asdfasdf asdflkasdasd


_______________________________________________
mirrorbrain-commits mailing list
Archive: http://mirrorbrain.org/archive/mirrorbrain-commits/

Note: To remove yourself from this list, send a mail with the content
 	unsubscribe
to the address mirrorbrain-commits-request_at_mirrorbrain.org