Here are some rough notes from thinking about better configs for a
future OpenSolaris release. The exact content isn't so important in the
short term as how to package it, but by all means comment on any aspect
of interest. Please ;)
--/--
Getting a production-ready Apache configuration in OpenSolaris 2008.11
The default configuration for Apache and unbundled modules like
mod_dtrace and
mod_php enables as many features as practical at the cost of performance.
Several changes are necessary for production configurations to limit the
memory
and CPU use.
A. loaded modules
For production, modules shouldn't be loaded if they aren't used, as they
consume memory and sometimes CPU even if they aren't configured.
Also, the set of loaded modules in a production config shouldn't be based
directly on which packages are installed.
httpd.conf loads all Apache-provided modules by virtue of these lines in
the
configuration:
<IfDefine 64bit>
Include /etc/apache2/2.2/conf.d/modules-64.load
</IfDefine>
<IfDefine !64bit>
Include /etc/apache2/2.2/conf.d/modules-32.load
</IfDefine>
Use alternate files production-modules-64.load* and
production-modules-32.load,
which load only the following basic set of modules:
mod_authz_host
mod_log_config
mod_env
mod_expires
mod_headers
mod_unique_id
mod_setenvif
mod_mime
mod_autoindex
mod_cgi (prefork MPM) or mod_cgid (worker MPM)
mod_dir
mod_actions
mod_alias
mod_rewrite
(*These files aren't provided but are easy to create.)
Any additional modules which are required must be added manually. Adding
further modules should be performed in conjunction with configuring the
related feature.
httpd.conf also loads several other add-on modules whose packages install
configuration snippets in /etc/apache2/2.2/conf.d, because of the following
lines in the configuration:
Include /etc/apache2/2.2/conf.d/*.conf
Reading a directory of .conf files is desireable, but a production config
shouldn't read that directly since its content depends on which packages
are installed.
Replace that include with
Include /etc/apache2/2.2/production-conf.d/*.conf
(This directory isn't created when the product is installed.)
Adding LoadModule directives for any additional modules will be done
only as necessary for features required in the production server.
B. Very basic MPM configuration
The choice of MPM may be based on the exact workload. At a minimum, we
need to fix the default configuration so that it doesn't allow the web
server to use too many system resources (processes, memory, swap space).
This section of httpd.conf needs to be removed:
<IfModule prefork.c>
ListenBacklog 8192
ServerLimit 2048
MaxClients 2048
</IfModule>
Copy samples-conf.d/mpm.conf to production-conf.d; that sample file
has reasonable, initial defaults for both worker and prefork MPMs. It
can be modified during later testing as necessary.
C. If you need to enable SSL
load mod_ssl from within production-modules-{32|64}.load
copy samples.d/ssl.conf to production-conf.d and modify for
your configuration
Is the cipher selection in ssl.conf reasonable? (good combination of
security + performance?)
MPM implications: Does SSL use heap library extensively, and thus
perform worse
with more threads per process? (guess: worker is fine with <= 100
threads per child)
D. If you need to enable name-based (non-SSL) virtual hosts
<VirtualHost www.example.com>
ServerName www.example.com:80
...
</VirtualHost>
define any configuration specific to this vhost, such as log files,
document root, etc.
If mod_rewrite configuration at global scope should apply to this
vhost, add "RewriteOptions inherit" within the vhost.
If global scope (outside of any VirtualHost) is not intended for
use, you can deny access.
MPM implications: none
E. If you need to enable web server authentication and authorization
(from definitions in LDAP, files, databases, etc.)
Note that some applications handle this internally and don't rely on
the web server.
MPM implications: which auth methods cache, and which are cross-process?
(mod_ldap has a shared-memory cache, which should help prefork; but
pooled server connections are specific to a child process so prefork
could perform worse)
F. If you need to host PHP applications
if prefork, copy conf.d/php5.2.conf to production-conf.d
if worker, copy samples.d/fcgid.conf to production-conf.d/php-fcgid.conf
and fix the AddHandler or Location container
MPM implications:
OpenSolaris mod_php refuses to work in worker MPM, right?
your PHP applications may use support libraries which aren't
thread-safe
if a small amount of your load is PHP, memory use can be reduced
by using
FastCGI to communicate with a small number of PHP processes,
instead of
hosting the PHP application in every Apache process
G. If you need to reverse proxy some requests to another server
MPM implications: pooled connections better utilized with worker
H. If you need to route requests to GlassFish or Tomcat
when to use mod_proxy_ajp vs. mod_proxy_http vs. mod_jk (and how)
MPM implications: pooled connections better utilized with worker
I. If you need to host mod_perl applications
do we have a sample for this?
MPM implications: prefork must be used
J. If you need to enable mod_disk_cache
we need a sample configuration for this to place the cache in an
appropriate
place
(not going to cover the 20 million Apache features; just those which are
commonly needed for production and require more than a few lines in the
config)
...
Z. real MPM tuning
among other things: make sure you drive Apache to MaxClients during
testing
and survive; otherwise, MaxClients may be too high
don't let MinSpareXXX and MaxSpareXXX be too close to each other, or
Apache
will continually create and terminate child processes; the difference
should be
a meaningful percentage of normal load (at least 20%?)
use mod_status to monitor utilization of processes/threads to
determine if
MaxClients is appropriate
and so on
--/--
new files that could be installed with Apache as part of these instructions:
/etc/apache2/2.2/httpd-production.conf:
like httpd.conf but has the changes mentioned above
/etc/apache2/2.2/production-conf.d/:
new directory where admin places conf snippets to activate features
within production config
/etc/apache2/2.2/production-conf.d/production-modules-{32|64}.load:
like conf.d/modules-{32|64}.load, but has just the core which are
required in just about every production config
Something like this would switch from the default enable-everything
config to this alternate config:
svccfg -s apache22 setprop httpd/startup_options = astring:
-f/etc/apache2/2.2/httpd-production.conf
