This paper discusses the planning of Web Services ==>HTTPD installation/Application module configuration ==> upgrade/maintenance, from the point of view of simplifying installation ==> performance Tuning ==> convenient maintenance.
The upgrade of Apache and the application modules such as PHP resin completely do not affect each other.
Summary:
Web application Capacity Planning: The planning of Web services and some simple estimating formulae based on the characteristics of hardware configuration and Web application;
Apache installation process: Apache's General simplified installation option, convenient for later application of the modular configuration;
Modify Hard_server_limit:
Vi/path/to/apache_src/src/include/httpd.h
#define HARD_SERVER_LIMIT 2560 <=== Add a "0" to the back of the original Hard_server_limit 256.
Apache compilation:
/path/to/apache_src/configure--prefix=/another_driver/apache--enable-shared=max--enable-module=most
Optional Application module/tool Installation: PHP resin mod_gzip mod_expire and the coordination between the modules;
PHP Installation:
/path/to/php_src/configure--with-apxs=/path/to/apache/bin/apxs--enable-track-vars--with-other-modules-you-need
Mod_resin Installation:
/path/to/resin/src/configure--with-apxs=/path/to/apache/bin/apxs
Mod_gzip Installation:
/path/to/apache/bin/apxs-i-a-c mod_gzip.c
Tools: Cronolog Installation: http://www.cronolog.org
Upgrade/maintenance: See how the common and modular installation process simplifies the daily upgrade/maintenance effort;
According to the above method: the responsibilities of the system administrator and the application administrator can be clearly separated and independent.
System installation: The responsibility of the system administrator is to install the system => install a can adapt to any situation Apache, and then Colon,
Application installation: The application Administrator is responsible for the specific application of the required modules and set the httpd.
System Upgrade: System Administrator: Upgrade the system/upgrade Apache
Application Upgrades: System administrator: Upgrading application Modules
Specific Description:
Capacity Planning for Web applications
Apache is primarily a memory-consuming service application, my personal summary of the empirical formula:
Apache_max_process_with_good_perfermance < (total_hardware_memory/apache_memory_per_process) * 2
apache_max_process = apache_max_process_with_good_perfermance * 1.5
Why would there be a apache_max_process_with_good_perfermance and apache_max_process? The reason is that the system can use more memory for file system caching at low load, thus further increasing the response speed of individual requests. Under high load, the system's single request response speed is much slower, and over apache_max_process, the system crashes because it starts using the hard disk for virtual memory swap space. In addition, the same service: The apache_max_process of 2G memory machines is typically set to only 1.7 times times that of 1G memory, because Apache itself can degrade as a result of managing more processes.
Example 1:
An Apache + mod_php server: An Apache process typically requires 4 m of memory
So on a 1G memory machine: Apache_max_process_with_good_perfermance < (1g/4m) * 2 = 500
apache_max_process = 500 * 1.5 = 750
So plan your application so that the service runs as far as 500 Apache below, and sets Apache's soft limit at 800.
Example 2:
An Apache + mod_resin server: An Apache process typically requires 2 m of memory
On a 2G-RAM machine: Apache_max_process_with_good_perfermance < (2g/2m) * 2 = 2000
Therefore: apache_max_process = 2000 * 1.5 = 3000
The above estimates are based on small file services (one request is typically below 20k). For file download type sites, you may also be affected by other factors such as bandwidth.
Apache installation process
The hard upper limit of the number of servers Hard_server_limit modification:
Apache's default maximum number of processes is 256 under FreeBSD and Linux, and other Unix operating systems need to be modified Apache_1.3.xx/src/include/httpd.h
#ifndef Hard_server_limit
#ifdef WIN32
#define HARD_SERVER_LIMIT 1024
#elif defined (NETWARE)
#define HARD_SERVER_LIMIT 2048
#else
#define HARD_SERVER_LIMIT 2560 <=== Add a "0" to the back of the original Hard_server_limit 256.
#endif
#endif
Explain:
The default maximum number of users in Apache is 256: This is a very good default setting for server memory or about 256M, but as the cost of memory drops dramatically, the server memory configuration of a large site now is generally a higher order of magnitude than it was then. So the hard limit of 256 processes is too wasteful for a 1G-RAM machine, and Apache's soft upper limit max_client is limited to hard_server_limit, so if the Web server has more memory than 256M, should be elevated to Apache Hard_server_limit. Based on personal experience: 2560 has been able to meet the capacity planning of most servers less than 2G of memory (Apache's soft limit planning please look back).
Apache compilation: Common compilation options to standardize the installation process
./configure--prefix=/another_driver/apache/--enable-shared=max--enable-module=most
Explain:
--prefix=/another_driver/apache/: A system with the lowest life is generally the hard drive, so: the service data and system completely separate, not only can improve the data access speed, more important, greatly facilitate system upgrades, backup and recovery.
--shared-module=max: Using dynamic loading can result in a 5% performance drop, but it's nothing compared to the benefits: for example, easy module upgrades, lower risk of system upgrades, standardization of installation process
--enable-module=most: Most can be used to compile some of the less commonly used modules, such as the Mod_expire described later, is not in the default common Apache module
If you don't want to build so, you can do this:
./configure \
"--with-layout=apache" \
"--prefix=/path/to/apache" \
"--disable-module=access" \
"--disable-module=actions" \
"--disable-module=autoindex" \
"--disable-module=env" \
"--disable-module=imap" \
"--disable-module=negotiation" \
"--disable-module=setenvif" \
"--disable-module=status" \
"--disable-module=userdir" \
"--disable-module=cgi" \
"--disable-module=include" \
"--disable-module=auth" \
"--disable-module=asis"
But the result will be found that this compilation of service performance can only slightly improve (about 5%), but lost the future system upgrades and module upgrade flexibility, whether the module or Apache itself upgrade must be all the source added together recompile.
The default configuration file for Apache is generally larger: we can use the method of removing annotations to streamline: And then go into the specific implant process to get you to customize what you need more quickly.
Grep-v "#" Httpd.conf.default >httpd.conf
There are several common items that need to be modified:
#服务端口, the default is 8080, it is recommended to adjust the entire Apache configuration and then change the service port to the official service port
Port 8080 => 80
#服务器名: No default
ServerName name.example.com
#最大服务进程数: Based on service capacity forecast settings
MaxClients 256 => 800
#缺省启动服务后的服务进程数: When the service is more stable, the httpd number can be set according to the average load
Startservers 5 => 200
Do not modify:
Previous suggestions were made to modify:
Minspareservers 5 => 100
Maxspareservers => 200
But from my experience, the default is already very optimized, and it's better to have Apache adjust the number of processes.
Special Modifications:
On Solaris or some applications that are more vulnerable to memory leaks:
Maxrequestsperchild 0 =>3000
Installation configuration for application modules and tools:
Because of the use of module dynamic loading mode, so you can easily through simple configuration adjustment to make the Apache you need: It is best to eliminate the most common modules (whether in safety or efficiency).
For example: for static page Server: On what module does not load, PHP application with PHP module, for Java application on the resin module load. and the various modules of the plug is very simple.
Generally, modules that are not required include:
#LoadModule Env_module libexec/mod_env.so
#LoadModule Negotiation_module libexec/mod_negotiation.so
#LoadModule Status_module libexec/mod_status.so
#server side include is obsolete.
#LoadModule Includes_module libexec/mod_include.so
#不需要将没有缺省index文件的目录下所有文件列出
#LoadModule Autoindex_module libexec/mod_autoindex.so
#尽量不使用CGI: It's always been the best place for Apache security.
#LoadModule Cgi_module libexec/mod_cgi.so
#LoadModule Asis_module libexec/mod_asis.so
#LoadModule Imap_module libexec/mod_imap.so
#LoadModule Action_module libexec/mod_actions.so
#不使用安全校验可以大大提高访问速度
#LoadModule Access_module libexec/mod_access.so
#LoadModule Auth_module libexec/mod_auth.so
#LoadModule Setenvif_module libexec/mod_setenvif.so
The best reservations are:
#用于定制log格式
LoadModule Config_log_module libexec/mod_log_config.so
#用于增加文件应用的关联
LoadModule Mime_module libexec/mod_mime.so
#用于缺省index文件: index.php etc.
LoadModule Dir_module libexec/mod_dir.so
Available for use are:
#比如: You need to debug PHP under ~/username/to
LoadModule Userdir_module libexec/mod_userdir.so
#比如: A previous URL needs to be turned on or a CGI Script-alias is required
LoadModule Alias_module libexec/mod_alias.so
Common modules:
The most common may be PHP and Java Web application wrapper, in addition, performance: Mod_gzip can reduce the flow of about 40%, thereby reducing the load of the machine for transmission, and mod_expires can reduce about 10% of duplicate requests, Allow duplicate user requests cache to be local and do not send requests to the server at all.
It is recommended that all module configurations be placed in the
Installation of PHP:
/path/to/php_src/configure--with-apxs=/path/to/apache/bin/apxs--with-other-modules-you-need
Configurations that need to be modified:
AddType application/x-httpd-php. php. php3. any_file_in_php
Installation settings for resin:
/path/to/resin/src/configure--with-apxs=/path/to/apache/bin/apxs
Typically, the specific resin settings are placed in a different file:
<ifmodule mod_caucho.c>
Cauchoconfigfile/path/to/apache/conf/resin.conf
</IfModule>
Installation configuration for Mod_expires:
<ifmodule mod_expires.c>
Expiresactive on
#所有的. gif file expires after 1 months
Expiresbytype image/gif "Access plus 1 month"
#所有的文件缺省1天以后过期
ExpiresDefault "now plus 1 day"
</IfModule>
Installation of Mod_gzip:
/path/to/apache/bin/apxs-i-a-c mod_gzip.c
Configuration of Mod_gzip and PHP
<ifmodule mod_gzip.c>
mod_gzip_on Yes
Mod_gzip_minimum_file_size 1000
Mod_gzip_maximum_file_size 300000
Mod_gzip_item_include file \.htm$
Mod_gzip_item_include file \.html$
Mod_gzip_item_include file \.php$
Mod_gzip_item_include file \.php3$
Mod_gzip_item_include MIME text/.*
Mod_gzip_item_include MIME Httpd/unix-directory
#不要让mod_gzip和php的session使用同一个临时目录: Php_session need to set session.save_path by php.ini =/tmp/php_sess
Mod_gzip_temp_dir/tmp/mod_gzip
Mod_gzip_dechunk Yes
Mod_gzip_keep_workfiles No
</IfModule>
Mod_gzip and mod_php: Do not let Mod_gzip and mod_php use the same temporary directory;
Mod_gzip and resin coordination: to let Mod_gzip after mod_caucho load, otherwise mod_gzip does not work
... othr modules
Addmodule mod_so.c
Addmodule mod_caucho.c
#notice: mod_gzip must load after Mod_caucho
Addmodule mod_gzip.c
Addmodule MOD_EXPIRES.C
...
Log Wheel tool Cronolog installation and setup: Cronolog can be very neat to store logs on a day-round basis
The default compilation is installed under/usr/local/bin/, just to change the configuration to:
The log will be truncated by day and stored in weekday directory name: For example: LOG/1 is Monday, LOG/5 is Friday, log/0 is Sunday
Upgrade Maintenance:
Due to the flexibility of installing Apache,apache's httpd Core Services and application modules and application modules in a standardized DSO mode, it is recommended that all stand-alone modules be configured with
<ifmodule mod_name>
Configurations..
</IfModule>
, this configuration is very easy to adjust by masking a module: for example:
#AddModule mod_gzip.c
Shielding the Mod_gzip, the other modules do not have any effect.
Installation and maintenance process:
System installation: The responsibility of the system administrator is to install the system and an Apache that can adapt to any situation, and then colon.
Application installation: The application Administrator is responsible for the specific application of the required modules and set the httpd.
System Upgrade: System Administrator: Upgrade the system/upgrade Apache
Application Upgrades: Application Manager: Upgrading application Modules
System backup/restore: If Apache is not on the default system disk, just want to backup the Apache directory, encounter system partition hardware problems directly using a prepared system colon, directly to the physical disk of Apache restore on the line.
System administrator: Apache's most simplified installation OS + Apache (httpd core only)
Application Administrator: Application module Customization +SO
+php
+so
+caucho
+ssl
Application: Pure static page service:
Image.example.com
www.example.com bbs.example.com mall.example.com
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
