I thought we were already checking for CMT installation and enabling the
kernel crypto ? At least it was there in Cool Stack. If you're adding
that, we should automatically also bump up the ServerLimit and
MaxClients for CMT.
This is simple to do in a postinstall script.
Shanti
On 02/18/09 09:21, Basant Kumar kukreja wrote:
> +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
> _______________________________________________
>
>
> webstack-discuss mailing list
> webstack-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
