+1 for production ready configuration.
Just a note that it is sometimes difficult to come up with a common production
config for different kind of servers. For example, ServerLimit and MaxClients
ServerLimit 2048
MaxClients 2048
For a larger system like CMT systems with more memory, these tunables can be
higher. Ideally it should be self tunable. For example, in Sun Web Server, we
tune few settings (if unspecified by user) based on Number of CPUs, memory etc.
For my above example, if ServerLimit is not specified by user then Webstack's
apache can define these values based on the system it is running on. In longer
term, we can work on a separate patch, which tunes some configuration
dynamically.
MPM and keep alive settings are the most common setting which should be tuned
dynamically unless user wants to override it.
For CMT systems, we can have separate include files too. (Where configuration
for built-in crypto card can be included)
Regards,
Basant.
On Tue, Feb 17, 2009 at 03:17:00PM -0500, 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 ;)
>
> --/--
>
> 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
>
> _______________________________________________
>
>
> webstack-discuss mailing list
> webstack-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
