Jeff Trawick wrote:
> 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 ;)
No prepackaged config is going to suit a real user.
The nearest we can come is to boil it down to "wizard" level,
where the user just defines things like virtual hosts. But we're
not really even near that. Nor, I think, should we be:
the server admin task should not be dumbed down to the point
where admins are likely to shoot themselves in the foot through
following recipes.
My point: how much effort should we really devote to it?
Alternative proposal: more educational material. This is inspired
in part by chats I had with some Sun folks at FOSDEM. The suggestion
is that I might put together some webcast tutorials on apache topics
we can offer as added value to our users. I'm quite keen on that
idea, starting with Apache but perhaps moving on to other webstack
components in due course.
++++
Having said that, it's good that you're giving the issue some thought.
Someone remind me: have we contemplated something along the lines
of Debian's a2ensite for generating virtualhost templates, for instance?
> 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.
Here's a thought inspired by your post: a script to scan an httpd.conf,
and highlight any modules loaded but not used. This is not trivial,
but shouldn't be too hard with a known set of modules, such as those
bundled as standard from apache.org.
> 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
Hmmm. There's very little in there that's really core.
I'd say drop mod_unique_id, and consider carefully whether
the bigger modules (cgi[d] and maybe rewrite) should
default to on. But that just illustrates the difficulty
in selecting a "core" set.
> (*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.
+1, with provisos as above. But that conjunction could apply to most
of the above modules too: both env modules, mod_expires, mod_headers,
mod_actions, and even mod_alias).
> 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.
This looks like it's heading towards something like Debian's a2enmod,
which makes a similar mods-available vs mods-enabled distinction.
I think that has some merit, but also causes a lot of confusion[1].
If we do go down this road, we should align what we do with what
Debian (and thus Ubuntu/etc) do rather than create yet another
variant to confuse the world.
> 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.
Presumably something like samples.d/www.example.com
> 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)
A lot of these sound like good material for tutorials, whether
webcast or written. Or ideally, give users the choice.
> 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
Talking of which, did you see Vincent Deffontaines' recent post on
httpd-docs concerning updating the performance tuning discussion
at httpd.apache.org?
> --/--
>
> 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
Won't those risk confusing more than they enlighten? I'd prefer
to keep httpd.conf as production, and use different names for
non-production samples. Again, see [1].
> /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
[1] http://www.theregister.co.uk/2006/11/04/apache_packages_support_vacuum/
--
Nick Kew
