Nick Kew wrote:
> 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
>>
This was done to provide better user experience. The assumption here is
that when the user installs a specific package
he/she intends to make use of its functionality.
>> 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.
>
I agree with Nick.
>> 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.
>>
Agree.
>> 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/
>
Instead of a new layout for the production environment, can't we make
the existing configuration layout
suitable for both developer and production environment ?
e.g., Have 2 sets of files - one to load the core / commonly used
modules and another one to load the non-core/uncommonly used modules.
By default, include both these files in either modules-*.load or in
httpd.conf. Since making the configuration production-ready involves
many manual steps, we can as well ask the user to comment or rename the
loading of non-core file.
Similarly, for config files in conf.d, unwanted ones can be moved to
samples-conf.d or renamed to something else (say *.unused).
Regards,
Seema.
