apache-优化

时间 2019-11-09

标签 apache 优化栏目 Apache 繁體版

原文原文链接

优化

性能优化
指定mpm模式（编译时）javascript

httpd -V show compile settings 及 Server MPM
-l Compiled in modules ,是否有worker.c 不然为preworkphp

apache 计算内存消耗
在压力测试时，找到httpd进程，查看一个进程使用了多少的内存，而后看看总的进程html

Apache内存使用量可使用下面命令：
ps -U apache u|awk '{S+=$6} END {print S}'
优化Apache(httpd)
KeepAlive 是否容许持续链接
MaxKeepAliveRequests 容许的持续链接的最大数
KeepAliveTimeout 持续链接在没有请求多少秒后切断
StartServers 最初启动时启动多少个服务器进程
MinSpareServers 空闲服务器进程的最小数
MaxSpareServers 空闲服务器进程的最大数
MaxRequestsPerChild 每一个子进程处理的最大请求数java

VPS优化Apache彻底设置node

1、削减模块以及计算调整可供APACHE使用的内存c++

影响WEB服务器最大的因素即为内存，因此咱们把它放在最前面web

在默认状态下，Apache会分配最大256个并发客户端链接，或者256个进程（每个都对应一个请求）。按照这种设置，一个流量巨大的网站会在顷刻间崩溃（即便你假设每一个进程占用5MB内存，那也须要1.3GB的内存来知足请求的数量）。若是不采起其它措施，系统会经过硬盘来尝试使用交换空间以处理它无法在物理内存中完成的任务。正则表达式

因此，咱们须要修改httpd.conf，使它使用最小的模块集
修改httpd.conf文件，保留
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule php5_module modules/libphp5.so
LoadModule fastcgi_module modules/mod_fastcgi.so数据库

去掉其它的模块apache

咱们配置的VPS服务器，系统加LAMP程序启动后总共在300M左右的内存，你可能但愿要求50％的物理内存都供Apache使用，这样，你须要肯定可让httpd真正使用的内存数。

首先准确计算出apache占用的进程数

ps -ef|grep httpd

root 21678 1 0 Jul19 ? 00:00:00 /usr/local/apache//bin/httpd -k start
vuser 21679 21678 0 Jul19 ? 00:00:00 /usr/local/apache//bin/httpd -k start
vuser 21714 21678 0 Jul19 ? 00:00:07 /usr/local/apache//bin/httpd -k start
vuser 21855 21678 0 Jul19 ? 00:00:07 /usr/local/apache//bin/httpd -k start
看apache是以什么用户启动的，而后咱们再用

ps -U vuser -u vuser u

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
vuser 29838 0.0 0.0 200404 5580 ? S 11:29 0:00 /usr/local/apache//bin/fcgi- -k start
vuser 29845 0.0 0.0 879952 7592 ? Sl 11:29 0:00 /usr/local/apache//bin/httpd -k start
vuser 29851 0.0 0.0 879952 7592 ? Sl 11:29 0:00 /usr/local/apache//bin/httpd -k start
(注：通常是用# ps -U apache -u apache u察看，但我这里运行apache的是vuser用户）

我们看到单个httpd进程使用了7.6 MB的RSS（驻留集大小）内存以及最大为88M左右的VSZ(虚拟内存)，这固然在很大程度上取决于你在Apache里加载和运行的模块数量。这决不是一个固定的数字。因为这个数字里还包含了共享库包，因此不是100％的准确。咱们能够认为RSS数字的一半是httpd线程真正使用的内存数，这可能还有点保守，可是离咱们的目的已经很是接近了，这样，咱们HTTPD线呈使用的内存数即为8M/2=4M

说明：MinSpareservers和MaxSpareServers分别设置空闲子进程的最小和最大数量，StartServers设置了服务器启动时创建的子进程数量。
ServerLimit 则是控制MaxClients所能使用的最大值。缩减MaxClients能让运行动态内容（好比：Drupal）的服务器有很大的改变。若是你的VPS 遭遇到流量的大幅增长，而你的MaxClients设置的过高的话，你的服务器将会无限循环工做于从物理内存交换页面到虚拟内存中，最终致使宕机。通常计算适当的MaxClients值取决于你总共可用的系统内存除于每一个Apache进程使用的内存。

计算MaxClient
MaxClients＝(总内存－预留内存)/单个APACHE子进程使用的内存。
那么咱们的1GRAM的VPS服务器的MaxClient即为：
MaxClients＝(1024-512)/4=128个

设置MaxRequestsPerChild

MaxRequestsPerChild 设置的是每一个子进程能够处理的请求数。每一个子进程在处理了MaxRequestsPerChild个请求后将自动销毁。0意味着无限，即子进程永不销毁。虽然缺省设为0可使每一个子进程处理更多的请求，但若是设成非零值也有两点重要的好处：

一、可防止意外的内存卸漏；
二、在服务器负载降低的时侯会自动减小子进程数。

所以，可根据服务器的负载来调整这个值，若是非零的话，vps上我的认为1000左右是比较合适的。事实上这个值对Apache的性能影响不是很大。

如下是本人在1G内存的VPS上经常使用的配置

StartServers 5
MinSpareServers 5
MaxSpareServers 20
ServerLimit 128
MaxClients 128
MaxRequestsPerChild 1000

它们要根据你的VPS的大小和你的Apache进程大小等来决定。

备注：
HostnameLookups 最好设置为off，不然会带来延迟，由于对每个请求都须要做一次DNS查询。若是你使用了任何”Allow from domain”或”Deny from domain”指令(也就是domain使用的是主机名而不是IP地址)，则代价是要进行两次DNS查询(一次正向和一次反向，以确认没有做假)。因此，为了获得最高的性能，应该避免使用这些指令(不用域名而用IP地址也是能够的)。若是网站空间中没有使用 Options FollowSymLinks，Apache就必须执行额外的系统调用以验证符号链接。为了不这种状况应该在全部地方都设置 FollowSymLinks。若是设置AllowOverride all，则Apache会试图对文件名的每个组成部分都打开.htaccess，如无必要应该对文件系统中全部的地方都使用 AllowOverride None。在Apache2.0可以忽略将要被发送的文件的内容的时候(好比发送静态内容)，若是操做系统支持sendfile() ，则Apache将使用内核提供的sendfile()来发送文件。使用sendfile能够经过免除分离的读和写操做来提高性能。咱们能够经过设置 EnableSendfile on来开启它。

2、优化KeepAlive

KeepAlive容许你的访问者在同一个TCP链接上完成多个请求，理论上它有助于提高反应时间，由于你的访问者能够在同一个链接上请求你的网页，图片和 javascripts。遗憾地是，Apache对于每一个请求都须要一个工做进程去处理。默认的每一个工做进程将持续打开15秒来处理每一个请求，即便你的访问者已经再也不使用它了！这也就意味着你的系统在任什么时候间都是缺乏工做进程的。咱们都但愿咱们那只有有限资源的小VPS能有确实在工做的工做进程。实现的方法之一是关闭KeepAlive。在你的httpd.conf文件中找到下面的一行：
KeepAlive On
而后将它改变为：
KeepAlive Off
若是你的网站有大量的图片和javascripts，一般最好仍是让KeepAlive保持打开，而后作些调整。
若是你决定让KeepAlive保持打开状态，改变默认的KeepAliveTimeout值就显得很重要了。它能避免链接没有在使用时仍然打开。在你的httpd.conf文件中找到下面一行：
KeepAliveTimeout 15
你只但愿链接打开5秒钟，这已经足够用户打开大部分必须的文件。因此改变此行为：
KeepAliveTimeout 5
若是你但愿让KeepAlive保持打开状态，同时应该增长MaxKeepAliveRequests。设置它为更大的值让每一个链接能够处理更多的请求，从而增长效率。找到这行：
MaxKeepAliveRequests 100
改变为：
MaxKeepAliveRequests 200

3、调整Timeout

另外一个较小的调整是改变TimeOut指令，这个调整能够获得小的性能提高和减少DDOS攻击的效果。这个指令用于设置Apache当接收新请求，处理请求和返回响应前需等待多少秒。找到这行：
Timeout 120
改变为：
Timeout 60

安装-基本配置

apache 4-19
下载后校验
md5sum -c xxxx.md5
升级apr 和apr-util
编译脚本参数
mod_deflate 由 zlib-dev 提供

启动脚本
cat apachectl 为脚本连接到etc/init.d 而后来连接至rc3.d rc.6.d

服务模式
独立模式和inetd模式
默认独立模式，效率高
inetd 超级服务，适合访问量较小
httd进程号在log/httpd.pid
kill log/httpd.pid

运行多个服务器
编译时指定安装目录
./configure --prefix=

httpd -l 列出编译的模块
查看httpd 工做模型
1，httpd -l 通常默认prefork
2，httpd -V

1，自带的监视器
mod_status
LoadModule status_module modules/mod_status.so #可加载
配置文件添加
131
132 SetHandler server-status
133 Order Allow,Deny
134 Allow from all
135
136
137 ExtendedStatus On

访问http://yourname/server-status?refresh
配置 mod_info 提供服务器的配置信息

字段                         说明
Server Version       Apache 服务器的版本。
Server Built         Apache 服务器编译安装的时间。
Current Time        目前的系统时间。
Restart Time         Apache 从新启动的时间。
Parent Server Generation        Apache 父程序 (parent process) 的世代编号，就是 httpd 接收到 SIGHUP 而从新启动的次数。
Server uptime         Apache 启动后到如今通过的时间。
Total accesses         到目前为此 Apache 接收的联机数量及传输的数据量。
CPU Usage           目前 CPU 的使用情形。
_SWSS....            全部 Apache process 目前的状态。每个字符表示一个程序，最多能够显示 256 个程序的状态。
Scoreboard Key         上述状态的说明。如下为每个字符符号所表示的意义：
    * _：等待连结中。
    * S：启动中。
    * R：正在读取要求。
    * W：正在送出回应。
    * K：处于保持联机的状态。
    * D：正在查找DNS。
    * C：正在关闭连结。
    * L：正在写入记录文件。
    * G：进入正常结束程序中。
    * I：处理闲置。
    * .：尚无此程序。
Srv        本程序与其父程序的世代编号。
PID        本程序的process id。
Acc        分别表示本次联机、本程序所处理的存取次数。
M         该程序目前的状态。
CPU        该程序所耗用的CPU资源。
SS         距离上次处理要求的时间。
Req        最后一次处理要求所耗费的时间，以千分之一秒为单位。
Conn       本次联机所传送的数据量。
Child       由该子程序所传送的数据量。
Slot        由该 Slot 所传送的数据量。
Client       客户端的地址。
VHost       属于哪个虚拟主机或本主机的IP。
Request     联机所提出的要求信息。

2，显示服务器版本
ServerTokens Prod[uctOnly] ：Server: Apache
使用curl -I IP 测试

3，持久链接 http/1.1
设置：KeepAlive On|Off
KeepAliveTimeout 15
测试
GET /URL HTTP/1.1
Host: 2.2.2.1

4，静态编译的模块
httpd -l
动态加载模块
Include conf.modules.d/*.conf
httpd -M | grep 模块
模块文件路径可以使用相对路径：相对于ServerRoot（默认/etc/httpd）

5，站点访问控制

可基于两种机制指明对哪些资源进行何种访问控制
访问控制机制有两种：客户端来源地址，用户帐号

》文件系统路径
<Directory “/path">
...

<File “/path/file”>
...

<FileMatch "PATTERN">
...

》 url 路径

<Location "">
...

<LocationMatch "">
...

示例

带match 为正则匹配

6，中“基于源地址”实现访问控制

(1) Options：后跟1个或多个以空白字符分隔的选项列表
在选项前的+，- 表示增长或删除指定选项
常见选项：
Indexes：指明的URL路径下不存在与定义的主页面资源相符的资
源文件时，返回索引列表给用户
FollowSymLinks：容许访问符号连接文件所指向的源文件（mv /etc/httpd/conf.d/welcome.conf{,.bk}）
None：所有禁用
All：所有容许

(2) AllowOverride

与访问控制相关的哪些指令能够放在指定目录下的.htaccess（由
    AccessFileName指定）文件中，覆盖以前的配置指令
    只对<directory>语句有效
    AllowOverride All: .htaccess中全部指令都有效
    AllowOverride None： .htaccess 文件无效
    AllowOverride AuthConfig .htaccess 文件中，除了AuthConfig 其它指
    令都没法生效

(3) 基于IP的访问控制:
无明确受权的目录，默认拒绝
容许全部主机访问：Require all granted
拒绝全部主机访问：Require all denied
控制特定的IP访问：
Require ip IPADDR：受权指定来源的IP访问
Require not ip IPADDR：拒绝特定的IP访问
控制特定的主机访问：
Require host HOSTNAME：受权特定主机访问
Require not host HOSTNAME：拒绝
HOSTNAME：
FQDN：特定主机
domin.tld：指定域名下的全部主机
不能有失败，至少有一个成功匹配才成功，即失败优先

Require all granted
Require not ip 172.16.1.1 拒绝特定IP

多个语句有一个成功，则成功，即成功优先

Require all denied
require ip 172.16.1.1 容许特定IP

日志配置：
      错误：
           ErrorLog logs/error_log
            LogLevel warn
            LogLevel 可选值: debug, info, notice, warn,error, crit, alert, emerg
                      
      访问日志：
      定义日志格式：LogFormat format strings
         LogFormat "%h %l %u %{%F %T}t \"%r\" %>s %b \"%{Referer}i\"
        \"%{User-Agent}i\""  testlog
        使用日志格式
        CustomLog logs/access_log testlog

7，定义路径别名：
Alias /URL/ "/PATH/" 访问url 匹配后改写至path

8，基于用户访问控制
认证质询：WWW-Authenticate：响应码为401，拒绝客户端请求，并说明要求客户端提供帐号和密码
认证：Authorization：客户端用户填入帐号和密码后再次发送请求报文；认证经过时，则服务器发送响应的资源
认证方式两种：basic：明文
digest：消息摘要认证,兼容性差

用户的帐号和密码
    虚拟帐号：仅用于访问某服务时用到的认证标识
    存储：文本文件，SQL数据库，ldap目录存储，nis等

配置示例：
<Directory “/path">
Options None
AllowOverride None
AuthType Basic
AuthName "String“ # 提示字符
AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE" #建立隐藏文件，文件使用ACL添加apache 访问权限 chmod 0600
Require user username1 username2 ...

容许帐号文件中的全部用户登陆访问：Require valid-user
在某一目录下建立密码文件，AuthUserFile
htpasswd [options] /PATH/HTTPD_PASSWD_FILE username
第一次加-c 建立文件，随后不用加选项

使用.htacesss
AuthType Basic
AuthName "String“ # 提示字符
AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE" #建立隐藏文件，文件使用ACL添加apache 访问权限 chmod 0600
Require user username1 username2 ...
在受控目录下添加
allowoverride authconfig

基于组帐号配置
  (1) 定义安全域
    <Directory “/path">
    AuthType Basic
    AuthName "String“
    AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE"
    AuthGroupFile "/PATH/HTTPD_GROUP_FILE"
    Require group grpname1 grpname2 ...
    </Directory>
   (2) 建立用户帐号和组帐号文件
    组文件：每一行定义一个组
    GRP_NAME: username1 username2 ..
           
       远程客户端和用户验证的控制
         Satisfy ALL|Any
        ALL 客户机IP和用户验证都须要经过才能够
        Any客户机IP和用户验证,有一个知足便可 
                           
        Require valid-user
        <RequireAll>
        Require all granted
        Require not ip 172.16.1.1
         </RequireAll>
        Satisfy Any   
            
    实现用户家目录的http共享        
            基于模块mod_userdir.so实现
            相关设置：
            vim /etc/httpd/conf.d/userdir.conf
            <IfModule mod_userdir.c>
            #UserDir disabled
            UserDir public_html #指定共享目录的名称
            </IfModule>
            准备目录
            su – wang;mkdir ~/public_html
            setfacl –m u:apache:x ~wang
            访问
             http://localhost/~wang/index.html
             
       ServerSignature On | Off | EMail  
        访问的网页不存在，显示服务器类型及端口，使用mail 会调用程序写mail  mail地址有
             ServerAdmin www-admin@foo.example.com  控制
    
    
  
             
             
             
            容器处理顺序

1 与，htacess
2
3
4

FAST-cgi 常驻内存独立于服务器，崩溃后不会影响到服务器自己
更安全，扩展性，同时处理多个请求
缺点：

别名，重定向
mod_alias
可将下载重定向至其余主机
permanent 301
temp 302
seeother 303
gone 410
redirect
redirectmatch 容许正则表达式

中止与重启
信号term
当即 kill -TERM cat /usr/local/apache2/logs/httpd.pid
信号 USER1
优雅重启 apachectl -k graceful
父进程建议子进程在完成它们如今的请求后退出
父进程从新读入配置文件并从新打开日志文件。每当一个子进程死掉，父进程马上用新的配置文件产生一个新的子进程并马上开始伺服新的请求

信号 HUP 当即重启
apachectl -k restart

信号：WINCH
apachectl -k graceful-stop
WINCH或graceful-stop信号使得父进程建议子进程在完成它们如今的请求后退出(若是他们没有进行服务，将会马上退出)。而后父进程删除PidFile并中止在全部端口上的监听。父进程仍然继续运行并监视正在处理请求的子进程，一旦全部子进程完成任务并退出或者超过由GracefulShutdownTimeout指令规定的时间，父进程将会退出。在超时的状况下，全部子进程都将接收到TERM信号并被强制退出

ps -U apache u | wc -l
sed -nr '/StartServers/,~6p' /etc/httpd/conf/httpd.conf

查看持续的输出
tail -f /var/log/httpd/error_log

vhost&mpm

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

ps aux|grep -v grep|awk '/httpd/{sum+=$6;n++};END{print sum/n}'

工做模式
prefork
多进程I/O模型，每一个进程响应一个请求，默认模型
一个主进程：生成和回收n个子进程，建立套接字，不响应请求
多个子进程：工做work进程，每一个子进程处理一个请求；系统初始时，预先生成多个空闲进程，等待请求，最大不超过1024个

prefork的配置：
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256 最多进程数,最大20000
MaxRequestsPerChild 4000 子进程最多能处理的请求数量。
在处理MaxRequestsPerChild 个请求以后,子进程将会被父进程终止，这时候子进程占用的内存就会释放(为0时永远不释放）

worker
：复用的多进程I/O模型,多进程多线程，IIS使用此模型
一个主进程：生成m个子进程，每一个子进程负责生个n个线程，每一个线程响应一个请求，并发响应请求：m*n
ServerLimit 16
StartServers 2
MaxRequestWorkers 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25

event 事件驱动模型（worker模型的变种
一个主进程：生成m个子进程，每一个进程直接响应n个请求，并发响应请求：m*n，有专门的线程来管理这些keep-alive类型的线程，当有真实请求时，将请求传递给服务线程，执行完毕后，又容许释放。这样加强了高并发场景下的请求处理能力

切换mpm
cat /etc/httpd/conf.modules.d/00-mpm.conf 启用相关的模式模块

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0

模块介绍：Apache 各个模块功能 基本(B)模块默认包含，必须明确禁用；扩展(E)/实验(X)模块默认不包含，必须明确启用。
        模块名称    状态    简要描述
        mod_actions (B) 基于媒体类型或请求方法，为执行CGI脚本而提供
        mod_alias (B) 提供从文件系统的不一样部分到文档树的映射和URL重定向
        mod_asis (B) 发送本身包含HTTP头内容的文件
        mod_auth_basic (B) 使用基本认证
        mod_authn_default (B) 在未正确配置认证模块的状况下简单拒绝一切认证信息
        mod_authn_file (B) 使用纯文本文件为认证提供支持
        mod_authz_default (B) 在未正确配置受权支持模块的状况下简单拒绝一切受权请求
        mod_authz_groupfile (B) 使用纯文本文件为组提供受权支持
        mod_authz_host (B) 供基于主机名、IP地址、请求特征的访问控制
        mod_authz_user (B) 基于每一个用户提供受权支持
        mod_autoindex (B) 自动对目录中的内容生成列表，相似于"ls"或"dir"命令
        mod_cgi (B) 在非线程型MPM(prefork)上提供对CGI脚本执行的支持
        mod_cgid (B) 在线程型MPM(worker)上用一个外部CGI守护进程执行CGI脚本
        mod_dir (B) 指定目录索引文件以及为目录提供"尾斜杠"重定向
        mod_env (B) 容许Apache修改或清除传送到CGI脚本和SSI页面的环境变量
        mod_filter (B) 根据上下文实际状况对输出过滤器进行动态配置
        mod_imagemap (B) 处理服务器端图像映射
        mod_include (B) 实现服务端包含文档(SSI)处理
        mod_isapi (B) 仅限于在Windows平台上实现ISAPI扩展
        mod_log_config (B) 容许记录日志和定制日志文件格式
        mod_mime (B) 根据文件扩展名决定应答的行为(处理器/过滤器)和内容(MIME类型/语言/字符集/编码)
        mod_negotiation (B) 提供内容协商支持
        mod_nw_ssl (B) 仅限于在NetWare平台上实现SSL加密支持
        mod_setenvif (B) 根据客户端请求头字段设置环境变量
        mod_status (B) 生成描述服务器状态的Web页面
        mod_userdir (B) 容许用户从本身的主目录中提供页面(使用"/~username")
        mod_auth_digest (X) 使用MD5摘要认证(更安全，可是只有最新的浏览器才支持)
        mod_authn_alias (E) 基于实际认证支持者建立扩展的认证支持者，并为它起一个别名以便于引用
        mod_authn_anon (E) 提供匿名用户认证支持
        mod_authn_dbd (E) 使用SQL数据库为认证提供支持
        mod_authn_dbm (E) 使用DBM数据库为认证提供支持
        mod_authnz_ldap (E) 容许使用一个LDAP目录存储用户名和密码数据库来执行基本认证和受权
        mod_authz_dbm (E) 使用DBM数据库文件为组提供受权支持
        mod_authz_owner (E) 基于文件的全部者进行受权
        mod_cache (E) 基于URI键的内容动态缓冲(内存或磁盘)
        mod_cern_meta (E) 容许Apache使用CERN httpd元文件，从而能够在发送文件时对头进行修改
        mod_charset_lite (X) 容许对页面进行字符集转换
        mod_dav (E) 容许Apache提供DAV协议支持
        mod_dav_fs (E) 为mod_dav访问服务器上的文件系统提供支持
        mod_dav_lock (E) 为mod_dav锁定服务器上的文件提供支持
        mod_dbd (E) 管理SQL数据库链接，为须要数据库功能的模块提供支持
        mod_deflate (E) 压缩发送给客户端的内容
        mod_disk_cache (E) 基于磁盘的缓冲管理器
        mod_dumpio (E) 将全部I/O操做转储到错误日志中
        mod_echo (X) 一个很简单的协议演示模块
        mod_example (X) 一个很简单的Apache模块API演示模块
        mod_expires (E) 容许经过配置文件控制HTTP的"Expires:"和"Cache-Control:"头内容
        mod_ext_filter (E) 使用外部程序做为过滤器
        mod_file_cache (X) 提供文件描述符缓存支持，从而提升Apache性能
        mod_headers (E) 容许经过配置文件控制任意的HTTP请求和应答头信息
        mod_ident (E) 实现RFC1413规定的ident查找
        mod_info (E) 生成Apache配置状况的Web页面
        mod_ldap (E) 为其它LDAP模块提供LDAP链接池和结果缓冲服务
        mod_log_forensic (E) 实现"对比日志"，即在请求被处理以前和处理完成以后进行两次记录
        mod_logio (E) 对每一个请求的输入/输出字节数以及HTTP头进行日志记录
        mod_mem_cache (E) 基于内存的缓冲管理器
        mod_mime_magic (E) 经过读取部分文件内容自动猜想文件的MIME类型
        mod_proxy (E) 提供HTTP/1.1的代理/网关功能支持
        mod_proxy_ajp (E) mod_proxy的扩展，提供Apache JServ Protocol支持
        mod_proxy_balancer (E) mod_proxy的扩展，提供负载平衡支持
        mod_proxy_connect (E) mod_proxy的扩展，提供对处理HTTP CONNECT方法的支持
        mod_proxy_ftp (E) mod_proxy的FTP支持模块
        mod_proxy_http (E) mod_proxy的HTTP支持模块
        mod_rewrite (E) 一个基于必定规则的实时重写URL请求的引擎
        mod_so (E) 容许运行时加载DSO模块
        mod_speling (E) 自动纠正URL中的拼写错误
        mod_ssl (E) 使用安全套接字层(SSL)和传输层安全(TLS)协议实现高强度加密传输
        mod_suexec (E) 使用与调用web服务器的用户不一样的用户身份来运行CGI和SSI程序
        mod_unique_id (E) 为每一个请求生成惟一的标识以便跟踪
        mod_usertrack (E) 使用Session跟踪用户(会发送不少Cookie)，以记录用户的点击流
        mod_version (E) 提供基于版本的配置段支持
        mod_vhost_alias (E) 提供大批量虚拟主机的动态配置支持
性能调优，模块启用/关闭
    (1)启用压缩
        LoadModule deflate_module modules/mod_deflate.so
    (2)启用重写
        LoadModule rewrite_module modules/mod_rewrite.so  
    (3)启用默认扩展，支持在这里进行修改httpd主要配置
        Include conf/extra/httpd-default.conf  
    (4)提供文件描述符缓存支持，从而提升Apache性能
        LoadModule file_cache_module modules/mod_file_cache.so
    (5)启用基于URI键的内容动态缓冲(内存或磁盘)  
        LoadModule cache_module modules/mod_cache.so  
    (6)启用基于磁盘的缓冲管理器
        LoadModule cache_disk_module modules/mod_cache_disk.so  
    (7)基于内存的缓冲管理器
        LoadModule socache_memcache_module modules/mod_socache_memcache.so 
    (8)屏蔽全部没必要要的模块
        #LoadModule authn_file_module modules/mod_authn_file.so  
        #LoadModule authn_dbm_module modules/mod_authn_dbm.so  
        #LoadModule authn_anon_module modules/mod_authn_anon.so  
        #LoadModule authn_dbd_module modules/mod_authn_dbd.so  
        #LoadModule authn_socache_module modules/mod_authn_socache.so  
        #LoadModule authn_core_module modules/mod_authn_core.so  
        #LoadModule authz_host_module modules/mod_authz_host.so  
        #LoadModule authz_groupfile_module modules/mod_authz_groupfile.so  
        #LoadModule authz_user_module modules/mod_authz_user.so  
        #LoadModule authz_dbm_module modules/mod_authz_dbm.so  
        #LoadModule authz_owner_module modules/mod_authz_owner.so  
        #LoadModule authz_dbd_module modules/mod_authz_dbd.so  
        LoadModule authz_core_module modules/mod_authz_core.so  
        LoadModule access_compat_module modules/mod_access_compat.so  
        #LoadModule auth_basic_module modules/mod_auth_basic.so  
        #LoadModule auth_form_module modules/mod_auth_form.so  
        #LoadModule auth_digest_module modules/mod_auth_digest.so 
    （9）已通过时屏蔽
        #LoadModule autoindex_module modules/mod_autoindex.so
    （10）用于定义缺省文档index.php、index.jsp等
        LoadModule dir_module modules/mod_dir.so
    （11）用于定义记录文件格式
        LoadModule log_config_module modules/mod_log_config.so
    （12）定义文件类型的关联
        LoadModule mime_module modules/mod_mime.so
    （13）减小10%左右的重复请求
        LoadModule expires_module modules/mod_expires.so  
    （14）容许apache修改或清除传递到cgi或ssi页面的环境变量
        LoadModule env_module modules/mod_env.so
    （15）根据客户端请求头字段设置环境变量，若是不须要则屏蔽掉
        #LoadModule setenvif_module modules/mod_setenvif.so
    （16）生成描述服务器状态的页面
        #LoadModule status_module modules/mod_status.so
    （17）别名
        LoadModule alias_module modules/mod_alias.so
    （18）url地址重写模块
        LoadModule rewrite_module modules/mod_rewrite.so
    （19）jk_mod 负载均衡调度模块
        LoadModule    jk_module modules/mod_jk.so 
    （20）过滤模块，使用缓存必须启用过滤模块
        LoadModule filter_module modules/mod_filter.so 
    （21）关闭服务器版本信息
        LoadModule version_module modules/mod_version.so
    （22）自动修正用户输入的url错误 
        LoadModule speling_module modules/mod_speling.so

配置虚拟机（基于Ip或端口）
/usr/share/doc/httpd-2.4.6/httpd-vhosts.conf

<VirtualHost *:@@Port@@>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "@@ServerRoot@@/docs/dummy-host.example.com"
ServerName dummy-host.example.com
ServerAlias www.dummy-host.example.com
ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common

虚拟网站的根目录 documentroot 若是没有在主配置文件受权访问，须要在虚拟配置目录中进行受权

<VirtualHost :80> 基于域名

<VirtualHost :8080> 主配置文件须要Listen 8080

域名跳转
目的：不带主机名跳到www,https跳转
1，添加虚拟机，路由重写
<VirtualHost :80>
ServerName www.mydomain.com
ServerAlias mydomain.com
RewriteEngine On
RewriteRule ^/(.)$ https://www.mydomain.com/$1 [R=301]

DocumentRoot "/var/www/html/test"
ServerName test71.example.com
ServerAlias test71 example.com

AllowOverride AuthConfig
AuthName " haha"
AuthType Basic
AuthUserFile /var/www/html/test/.htpasswd
require valid-user

还须要 htpasswd -cm /var/www/html/test/.htpasswd redhat

网站文件压缩

https
yum -y install mod_ssl
vim /etc/httpd/conf.d/ssl.conf
默认目录及虚拟机目录之间关系

自动生成CA证书脚本
rpm -q openssl &> /dev/null || yum -y install openssl
mkdir ssl && cd ssl
cat >tt <<EOF
CN
HENAN
zhengzhou
magedu
devs
www.magedu.com
admin@magedu.com
EOF

genarate CA KEY & CA cert

( umask 066;openssl genrsa 2048 > cakey.pem )
echo -e " \e[1;32m start create cakey & cacert..... \e[0m "
sleep 5
openssl req -new -x509 -key cakey.pem -out cacert.pem -days 3650 < tt
echo
echo -e "\e[1;32m start genarate httpd.key & httpd.csr...\e[0m "
sleep 5
openssl req -newkey rsa:1024 -nodes -keyout httpd.key > httpd.csr < tt
echo
echo -e "\e[1;32m genrate httpd.crt....\e[0m"
sleep 5
openssl x509 -req -in httpd.csr -CA cacert.pem -CAkey cakey.pem -set_serial 01 > httpd.crt
echo
echo -e "\e[1;32m you can check the info from use : \e[0m "
echo -e "openssl x509 -in httpd.crt -noout -text \n copy the directory to the destinary ! "

防盗链
1，httpd.conf
虚拟机网站配置添加重写路由

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://maixj.net/.$ [NC]
RewriteCond %{HTTP_REFERER} !^http://maixj.net$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.maixj.net/.$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.maixj.net$ [NC]
RewriteCond %{REQUEST_URL} !^/pics/.$ [NC]
RewriteRule ..(gif|jpg|jpeg|png|bmp|mp3)$ http://www.maixj.net/pics/nolink.jpg [L,NC]
[NC] 表示not case sensitive，大小写无关
2，.htacess

SetEnvIfNoCase 和 access 技术

http请求版本区别

http请求流程：
一次HTTP操做称为一个事务
大体分为四个过程：
1，创建链接
在浏览器地址栏输入请求资源的url后，首先会在DNS本地缓存表查找域名对应的IP，若有则直接返回,若是没有则要求DNS进行查找，查找结束后返回给浏览器IP，获取IP后，客户端开始与服务器端经过tcp创建三次握手，链接成功后，开始进行下一步http请求。

DNS：首先在本地hosts文件下查找是否有域名对应的ip,如无，则在resolve.conf文件里查找dns服务器，找到后将DNS解析请求发送给DNS服务器，由dns服务器经过递归及迭代查询，并将结果返回。
网络链接：客户端根据获取到的IP，选择一个端口，建立一个套接字，经过OSI网络协议寻址路由，将数据包发送到指定ip地址的机器上，若是该IP与本机IP处于同一网段，则数据直接传送，如不在同一网段，默认将该数据包发往网关。经过三次握手创建数据链接通道，此时服务器端已经在指定的端口创建监听。

2，浏览器向web服务器发出请求报文。
http请求报文：
一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成

1.请求行
请求行分为三个部分：请求方法、请求地址和协议版本

请求方法

    HTTP/1.1 定义的请求方法有8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

    最常的两种GET和POST，若是是RESTful接口的话通常会用到GET、POST、DELETE、PUT。

    请求地址

    URL:统一资源定位符，是一种自愿位置的抽象惟一识别方法。

    组成：<协议>：//<主机>：<端口>/<路径>
    端口和路径有时能够省略（HTTP默认端口号是80）

    协议版本
    协议版本的格式为：HTTP/主版本号.次版本号，经常使用的有HTTP/1.0和HTTP/1.1


    2.请求头部
    请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。

3.请求数据

3，web服务器解析请求，根据方法，资源，首部，和可选的主题对请求处理。对请中的静态或动态资源处理，构建响应报文，web服务器经过链接响应报文，而后将访问记录计入日志。
根据服务程序的响应模型，对于一个请求，服务程序又有多个不一样的处理模型进行处理。
响应报文：

HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成
1.状态行
由3部分组成，分别为：协议版本，状态码，状态码描述。

其中协议版本与请求报文一致，状态码描述是对状态码的简单描述，因此这里就只介绍状态码。

状态码

状态代码为3位数字。
1xx：指示信息--表示请求已接收，继续处理。
2xx：成功--表示请求已被成功接收、理解、接受。
3xx：重定向--要完成请求必须进行更进一步的操做。
4xx：客户端错误--请求有语法错误或请求没法实现。
5xx：服务器端错误--服务器未能实现合法的请求

   2.响应头部     
   3.响应数据

4，应答结束后，关闭链接。

通常一个请求事务结束后，关闭网络链接
   TCP四次挥手
   
 tcp链接通常流程

http协议版本

1，http 0.9
只容许get请求，不支持请求头，只支持纯文本，回应HTML格式字符串，
典型的无状态，每一个事务独立处理，处理结束后释放链接，若是请求页面不存在，不会返回任何错误代码

2，http 1.0
请求与响应支持头域
每一个链接为一个事务，一个请求数据回应后，关闭链接，若有其余请求，须要新建链接
响应对象以一个响应状态行开始
支持Content-Type 数据格式
响应对象不仅限于超文本
开始支持客户端经过POST方法向Web服务器提交数据，支持GET、HEAD、POST方法
支持长链接（但默认仍是使用短链接），缓存机制，以及身份认证

3，http 1.1
引入持久链接,即tcp链接默认不关闭，能够被多个请求复用，不用声明keep-alive
管道机制：即在同一个TCP链接里，客户端能够同时发送多个请求，进一步改进了HTTP协议的效率
新增方法：PUT、PATCH、OPTIONS、DELETE
同一个TCP链接里，全部的数据通讯是按次序进行的。服务器只能顺序处理回应，前
面的回应慢，会有许多请求排队，形成"队头堵塞"（Head-of-line blocking）
为避免上述问题，两种方法：一是减小请求数，二是同时多开持久链接。网页优化技
巧，如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等
HTTP 协议不带有状态，每次请求都必须附上全部信息。请求的不少字段都是重复的，
浪费带宽，影响速度

关键特性：keep-alive   chunked    字节范围请求，请求流水线
 keep-alive  容许HTTP设备在事务处理结束以后将TCP链接保持在打开的状态，一遍将来的HTTP请求重用如今的链接，直到客户端或服务器端决定将其关闭为止。
 • chunked编码传输

该编码将实体分块传送并逐块标明长度,直到长度为0块表示传输结束, 这在实体长度未知时特别有用(好比由数据库动态产生的数据)
• 字节范围请求
HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，能够只向服务器请求一部分。该功能经过在请求消息中引入了range头域来实现，它容许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。若是服务器相应地返回了对象所请求范围的内容，则响应码206（Partial Content）

请求流水线：持续发送请求，没必要等服务器响应
新特性：
请求消息和响应消息都应支持Host头域
在HTTP1.0中认为每台服务器都绑定一个惟一的IP地址，所以，请求消息中的URL并无传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），而且它们共享一个IP地址。所以，Host头的引入就颇有必要了。
新增了一批Request method
HTTP1.1增长了OPTIONS,PUT, DELETE, TRACE, CONNECT方法
缓存处理
HTTP/1.1在1.0的基础上加入了一些cache的新特性，引入了实体标签，通常被称为e-tags，新增更为强大的Cache-Control头。

4，http2.0

头信息和数据体都是二进制，称为头信息帧和数据帧
复用 tcp链接：在一个链接里，客户端和浏览器均可以同时发送多个请求或回应，且不用按顺序一一对应，避免了“队头堵塞“,此双向的实时通讯称为多工（Multiplexing）
引入头信息压缩机制（header compression）,头信息使用gzip或compress
压缩后再发送；客户端和服务器同时维护一张头信息表，全部字段都会存入
这个表，生成一个索引号，不发送一样字段，只发送索引号，提升速度
HTTP/2 容许服务器未经请求，主动向客户端发送资源，即服务器推送
（server push）

多路复用（二进制分帧）
HTTP 2.0最大的特色: 不会改动HTTP 的语义，HTTP 方法、状态码、URI 及首部字段，等等这些核心概念上一如往常，却能致力于突破上一代标准的性能限制，改进传输性能，实现低延迟和高吞吐量。而之因此叫2.0，是在于新增的二进制分帧层。在二进制分帧层上， HTTP 2.0 会将全部传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码，其中HTTP1.x的首部信息会被封装到Headers帧，而咱们的request body则封装到Data帧里面
头部压缩
当一个客户端向相同服务器请求许多资源时，像来自同一个网页的图像，将会有大量的请求看上去几乎一样的，这就须要压缩技术对付这种几乎相同的信息。
随时复位
HTTP1.1一个缺点是当HTTP信息有必定长度大小数据传输时，你不能方便地随时中止它，中断TCP链接的代价是昂贵的。使用HTTP2的RST_STREAM将能方便中止一个信息传输，启动新的信息，在不中断链接的状况下提升带宽利用效率。
服务器端推流: Server Push
客户端请求一个资源X，服务器端判断也许客户端还须要资源Z，在无需事先询问客户端状况下将资源Z推送到客户端，客户端接受到后，能够缓存起来以备后用。
优先权和依赖
每一个流都有本身的优先级别，会代表哪一个流是最重要的，客户端会指定哪一个流是最重要的，有一些依赖参数，这样一个流能够依赖另一个流。优先级别能够在运行时动态改变，当用户滚动页面时，能够告诉浏览器哪一个图像是最重要的，你也能够在一组流中进行优先筛选，可以忽然抓住重点流。

HTTP1.0和HTTP1.1的区别

 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来作为缓存判断的标
准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match,
If-None-Match等更多可供选择的缓存头来控制缓存策略
 带宽优化及网络链接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是须要某
个对象的一部分，而服务器却将整个对象送过来了，而且不支持断点续传功能，HTTP1.1则在
请求头引入了range头域，它容许只请求资源的某个部分，即返回码是206（Partial Content），
方便了开发者自由的选择以便于充分利用带宽和链接
 错误通知的管理，在HTTP1.1中新增24个状态响应码，如409（Conflict）表示请求的资源与资
源当前状态冲突；410（Gone）表示服务器上的某个资源被永久性的删除
 Host头处理，在HTTP1.0中认为每台服务器都绑定一个惟一的IP地址，所以，请求消息中的
URL并无传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上能够
存在多个虚拟主机（Multi-homed Web Servers），而且它们共享一个IP地址。HTTP1.1的请
求消息和响应消息都应支持Host头域，且请求消息中若是没有Host头域会报告一个错误（400
Bad Request）
 长链接，HTTP 1.1支持长链接（PersistentConnection）和请求的流水线（Pipelining）处理，
在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟，在
HTTP1.1中默认开启Connection： keep-alive，弥补了HTTP1.0每次请求都要建立链接的缺点
HTTP1.x在传输数据时，每次都须要从新创建链接，无疑增长了大量的延迟时
间，特别是在移动端更为突出
HTTP1.x在传输数据时，全部传输的内容都是明文，客户端和服务器端都没法
验证对方的身份，没法保证数据的安全性
 HTTP1.x在使用时，header里携带的内容过大，增长了传输的成本，而且每次
请求header基本不怎么变化，尤为在移动端增长用户流量
 虽然HTTP1.x支持了keep-alive，来弥补屡次建立链接产生的延迟，可是keepalive使用多了一样会给服务端带来大量的性能压力，而且对于单个文件被不断
请求的服务(例如图片存放网站)，keep-alive可能会极大的影响性能，由于它在
文件被请求以后还保持了没必要要的链接很长时间

获取网页的方式（事务）
串行依次三次握手获取资源四次挥手（一个进程）
并行并行三次握手获取资源四次回收（并行多个进程）

串行持久链接：一次链接多个请求
管道化持久：

http版本特性区别
web服务器请求处理步骤
web访问响应模型

2.4默认支持持久链接
测试持久链接：
telnet

长短链接根据业务场景

2.4
文件夹须要受权才能访问

文件共享 index
已受权目录
options +-

welcome 配置文件更名

测试全局或在某个目录下
浏览器有缓存，强制刷新 CTRL+ f5
虚拟机配置内重定向(a--->b)
redirect tmp / http://xxx.xxxx.com

a>>>>https
https://

报错：重顶向次数太多
使用 rewriterule 进行重定向

sendfile
通常文件在本机能够启用sendfile

apache 反向代理

访问量

IP(独立IP)：即Internet Protocol,指独立IP数。一天内来自相同客户机IP地址只计算一次，记录远程客户机IP地址的计算机访问网站的次数，是衡量网站流量的重要指标.
PV(访问量)：即Page View, 页面浏览量或点击量，用户每次刷新即被计算一次，PV反映的是浏览某网站的页面数，PV与来访者的数量成正比，PV并非页面的来访者数量，而是网站被访问的页面数量
UV(独立访客)：即Unique Visitor,访问网站的一台电脑为一个访客。一天内相同的客户端只被计算一次。能够理解成访问某网站的电脑的数量。网站判断来访电脑的身份是经过来访电脑的cookies实现的。若是更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数是不变的。

QPS：request per second，每秒请求数
PV，QPS,并发链接数换算公式
QPS= PV* 页面衍生链接次数/ 统计时间（86400）
并发链接数 =QPS * http平均响应时间

峰值时间：天天80%的访问集中在20%的时间里，这20%时间为峰值时间
峰值时间每秒请求数(QPS)=( 总PV数 *页面衍生链接次数）*80% ) / ( 天天秒数* 20% )


建设一个能承受500万PV/天天的网站吗？ 500万PV是什么概念？服务器每秒要处理多少个请求才能应对？若是计算呢
计算模型：
每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%)) / 服务器数量 。
其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）

简单计算的结果：

((80%500万)/(24小时60分60秒40%))/1 = 115.7个请求/秒
((80%100万)/(24小时60分60秒40%))/1 = 23.1个请求/秒

初步结论：
如今咱们在作压力测试时，就有了标准，若是你的服务器一秒能处理115.7个请求，就能够承受500万PV/天天。若是你的服务器一秒能处理23.1个请求，就能够承受100万PV/天天

留足余量：

以上请求数量是均匀的分布在白天的9.6个小时中，但实际状况并不会这么均匀的分布，会有高峰有低谷。为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。

115.7个请求/秒 *2倍=231.4个请求/秒

115.7个请求/秒 *3倍=347.1个请求/秒

23.1个请求/秒 *2倍=46.2个请求/秒

23.1个请求/秒 *3倍=69.3个请求/秒

最终结论：

若是你的服务器一秒能处理231.4--347.1个请求/秒，就能够应对平均500万PV/天天。

若是你的服务器一秒能处理46.2--69.3个请求，就能够应对平均100万PV/天天。
说明：
这里说明每秒N个请求，就是QPS。由于我关心的是应用程序处理业务的能力。

实际经验：

一、根据实际经验，采用两台常规配置的机架式服务器，配置是很常见的配置，例如一个4核CPU+4G内存+服务器SAS硬盘。

二、我的武断的认为在服务器CPU领域Intel的CPU要优于AMD的CPU，有反对的就反对吧，我都说我武断了（请看CPU性能比较），不要太相信AMD的广告，比较CPU性能简单办法就是比价格，不要比频率与核心数，价格相差很少的性能也相差很少。

三、硬盘的性能很重要，由其是数据库服务器。通常的服务器都配1.5万转的SAS硬盘，高级一点的能够配SSD固态硬盘，性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。（本例仍是配置最多见的1.5万转的SAS硬盘吧）

四、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的很差量化)，是论坛类型的应用(总有回帖,不太容易作缓存,也没法静态化)。

五、以上软硬件状况下，是能够承受100万PV/天天的。(已留有余量应对忽然的访问高峰)

注意机房的网络带宽：

有人说以上条件我都知足了，但实际性能仍是达不到目标。这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，极可能你在机房是与你们共享一条100M的光纤，实际每一个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价格）。

一天总流量：每一个页面20k字节*100万个页面/1024=19531M字节=19G字节，

19531M/9.6小时=2034M/小时=578K字节/s 若是请求是均匀分布的，须要5M（640K字节）带宽（5Mb=640KB 注意大小写，b是位，B是字节，差了8倍），但全部请求不多是均匀分布的，当有高峰时5M带宽必定不够，X2倍就是10M带宽。10M带宽基本能够知足要求。

以上是假设每一个页面20k字节，基本不包含图片，要是包含图片就更大了，10M带宽也不能知足要求了。你自已计算吧。

性能测试基本概念
---------------------------------------------------------------------------------------
基本概念：
Throughput（吞吐量）：按照常规理解网络吞吐量表示在单位时间内经过网卡数据量之和，其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。一个100Mb(位)的双工网卡，最大发送数据的速度是12.5M字节/s ，最大接收数据的速度是12.5M字节/s，能够同时收发数据。
并发用户数：是同时执行操做的用户(线程数)。
响应时间：从请求发出到收到响应花费的时间。

QPS - Queries Per Second 每秒处理的查询数（若是是数据库，就至关于读取）
TPS - Transactions Per Second 每秒处理的事务数(若是是数据库，就至关于写入、修改)
IOPS，每秒磁盘进行的I/O操做次数

例如对某个数据库测试，分开两次测QPS与TPS。
QPS（读取）值老是高于TPS(写、改)，而且有倍率关系，由于：
一、数据库对查询可能有缓存。
二、机械硬盘或SSD硬盘的读就是比写快。

PV=page view
TPS=transactions per second
QPS=queries per second
RPS=requests per second
RPS=并发数/平均响应时间

一个小例子：
一个典型的上班签到系统，早上8点上班。7点半到8点这30分钟的时间里用户会登陆签到系统进行签到。公司员工为1000人，平均每个员上登陆签到系统的时长为5分钟。可以用如下的方法计算。
QPS = 1000/(3060) 事务/秒
平均响应时间为 = 560 秒
并发数= QPS平均响应时间 = 1000/(3060) (560)=166.7

通常衡量网站性能有哪些指标？
性能指标主要有响应时间，吞吐量，并发量，性能计数器。
1）响应时间指应用执行一个操做须要的时间，即从发出请求到最后收到响应数据所须要的时间。

系统经常使用操做响应时间表

实践中一般采用的办法是重复请求，好比一个请求操做重复执行1万次，测试一万次执行的总响应时间之和，而后除以1万，就获得单次请求的响应时间
2）吞吐量
指单位时间内系统处理的请求数量，体现系统的总体处理能力。对于网站，可用“请求数/秒”、“页面数/秒”或“访问人数/天”、“处理业务数/小时”等来衡量。重要指标有TPS(每秒处理的事物数)、QPS(每秒查询的请求数)、HPS（每秒HTTP请求数）等。
3）并发量
指系统可以同时处理的请求的数目，这个数字反映了系统的负载性能。对于网站而言，并发数指网站用户同时提交请求的用户数目。
4）性能计数器
描述服务器或操做系统性能的一些数据指标。如System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等使用状况。经过对这些指标设置报警阈值，当监控系统发现性能计数器超过阈值时，就向开发人员和运维报警，及时发现异常并处理。

怎么测试网站性能？
性能测试具体能够细分为性能测试、负载测试、压力测试、稳定性测试。
1）性能测试
以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内是否能达到预期。
2）负载测试
对系统不断增长并发请求以增长系统压力，直到系统的某项或多项性能指标达到安全临界值，这时继续对系统施加压力，系统的处理能力不但不会提升，反而会降低。
3）压力测试
超过安全负载的状况下，对系统施加压力，直到系统崩溃或不能再处理任何请求，以此得到系统最大压力承受能力。
4）稳定性测试
被测试系统在特定硬件、软件、网络环境条件下，给系统加载必定业务压力，使系统运行一段较长时间，以此检验系统是否稳定。

压力测试工具备http_load、apache ab、siege。
1）http_load
http_load -p 并发访问进程数 -f 访问总数须要访问的URL文件
http_load -r 每秒访问频率 -s 访问时间须要访问的URL文件
// 参数说明：一般参数pf一块儿使用，参数rs一块儿使用。
-parallel 简写 -p ：并发的用户进程数。
-fetches 简写 -f ：总计的访问次数。
-rate 简写 -r ：每秒的访问频率。
-seconds 简写 -s ：总计的访问时间。

新建一个urls.txt，urls.txt 是一个url 列表，每一个url 单独的一行。
在文件中加入一行：http://www.acme.com/software/http_load/
① 测试网站是否能承受住预期的访问压力
执行http_load -rate 5 -seconds 10 urls.txt，含义为在10秒内保持必定的频率访问目标url。

反馈分析
fetches, 6 max parallel, 253264 bytes, in 10.0031 seconds
// 说明在上面的测试中运行了48个请求，最大的并发进程数是6，总计传输的数据是253264bytes，运行的时间是10.0031秒
5276.33 mean bytes/connection
// 说明每次链接平均传输的数据量是5276.33bytes。253264/48=5276.33
4.7985 fetches/sec, 25318.5 bytes/sec
// 说明每秒的响应请求为4.7985个，每秒传递的数据为25318.5 bytes
msecs/connect: 251.601 mean, 1493.45 max, 26.176 min
// 说明每次链接的平均响应时间是251.601 毫秒，最大的响应时间1493.45 毫秒，最小的响应时间26.176 毫秒
msecs/first-response: 232.251 mean, 796.783 max, 39.402 min
// 说明每次链接的平均返回时间是232.251 毫秒，最大的响应时间796.783 毫秒，最小的响应时间39.402 毫秒
HTTP response codes:
code 200 -- 48
// 说明HTTP返回码是200，一共48次。

主要参考fetches/sec、msecs/connect数值，
前者对应QPS，表示每秒的响应请求数，后者对应response time，表示每一个链接的响应时间。

② 测试网站每秒所能承受的平均访问量
执行http_load -parallel 5 -fetches 1000 urls.txt，含义为同时使用5个进程，随机访问urls.txt中的网址列表，总共访问1000次。

fetches, 5 max parallel, 2。607e+06 bytes, in 328.806 seconds
mean bytes/connection
3.04131 fetches/sec, 7928.69 bytes/sec
msecs/connect: 772.326 mean, 19478.3 max, 219.936 min
msecs/first-response: 830.46 mean, 10006.4 max, 237.957 min
HTTP response codes:
code 200 — 1000

从上面结果看，目标网站仅仅可以承受每秒3次的访问，不够强壮。

2）apache ab

ab -c 并发数 -n 请求数 URL
// 参数说明：
-n 在测试会话中所执行的请求个数。默认时，仅执行一个请求
-c 一次产生的请求个数。默认是一次一个。
-t 测试所进行的最大秒数。其内部隐含值是-n 50000。它可使对服务器的测试限制在一个固定的总时间之内。默认时，没有时间限制。

执行ab -n 100 -c 100 http://127.0.0.1/test/test.php，含义为同时处理100个请求并运行100次test.php，模拟100个并发用户，对一个页面发送100个请求。

Server Software: Apache/2.4.23 // 服务器名称，apache 版本2.4.23
Server Hostname: 127.0.0.1 // 服务器主机名
Server Port: 80 // 服务器端口

Document Path: /test/test.php // 请求的URL中的根绝对路径，经过该文件的后缀名，咱们通常能够了解该请求的类型
Document Length: 54 bytes // HTTP响应数据的正文长度

Concurrency Level: 100 // 并发用户数
Time taken for tests: 0.085 seconds // 整个测试持续的时间，全部这些请求被处理完成所花费的总时间
Complete requests: 100 // 完成的请求数量
Failed requests: 0 // 失败的请求数量
Total transferred: 25600 bytes // 全部请求的响应数据长度总和，包括每一个HTTP响应数据的头信息和正文数据的长度
HTML transferred: 5400 bytes // 全部请求的响应数据中正文数据的总和，也就是减去了Total transferred中HTTP响应数据中的头信息的长度。
Requests per second: 1177.59 [#/sec] (mean) // 吞吐率，计算公式：Complete requests/Time taken for tests。至关于每秒事务数，后面括号中的 mean 表示这是一个平均值。吞吐率越高，服务器性能越好。
Time per request: 84.919 [ms] (mean) // 用户平均请求等待时间，计算公式：Time token for tests/（Complete requests/Concurrency Level）。至关于平均事务响应时间，后面括号中的 mean 表示这是一个平均值。
Time per request: 0.849 [ms] (mean, across all concurrent requests) // 服务器平均请求等待时间，计算公式：Time taken for tests/Complete requests，正好是吞吐率的倒数。也能够这么统计：Time per request/Concurrency Level。
Transfer rate: 294.40 [Kbytes/sec] received //这些请求在单位时间内从服务器获取的数据长度，即平均每秒网络上的流量，计算公式：Total trnasferred/ Time taken for tests，这个统计很好的说明服务器的处理能力达到极限时，其出口宽带的需求量，能够帮助排除是否存在网络流量过大致使响应时间延长的问题。

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.4 2 3
Processing: 6 44 23.4 46 81
Waiting: 6 44 23.5 46 81
Total: 8 46 23.1 47 82
// 网络上消耗的时间的分解
Percentage of the requests served within a certain time (ms)
50% 47
66% 60
75% 66
80% 72
90% 76
95% 80
98% 82
99% 82
100% 82 (longest request)
// 这部分数据用于描述每一个请求处理时间的分布状况，好比以上测试，66%的请求处理时间都不超过60ms，这个处理时间是指前面的Time per request，即对于单个用户而言，平均每一个请求的处理时间。

系统性能指标
https://www.cnblogs.com/sunshineliulu/p/7516034.html

1、经典公式1：
   通常来讲，利用如下经验公式进行估算系统的平均并发用户数和峰值数据

1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3根号C
    C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
    C’是并发用户数峰值

  举例1，假设系统A，该系统有3000个用户，平均天天大概有400个用户要访问该系统（能够从系统日志从得到），对于一个典型用户来讲，一天以内用户从登录到退出的平均时间为4小时，而在一天以内，用户只有在8小时以内会使用该系统。
那么，
  平均并发用户数为：C = 4004/8 = 200
  并发用户数峰值为：C‘ = 200 + 3*根号200 = 243

举例2，某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询本身的薪酬信息，但并非每一个人都会用这个系统，假设只有50%的人会按期用该系统，这些人里面有70%是在每月的最后一周使用一次该系统，且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为（朝九晚五）：
n = 1700000.50.7/5 = 11900
C= 119005/60/8 = 124

吞吐量计算为：F = Vu R / T 单位为个/s
F为事务吞吐量，Vu为虚拟用户数个数，R为每一个虚拟用户发出的请求数，T为处理这些请求所花费的时间

2、通用公式2：
对绝大多数场景，咱们用（用户总量/统计时间）影响因子（通常为3）来进行估算并发量。
好比，以乘坐地铁为例子，天天乘坐人数为5万人次，天天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为5000080%/（36060）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数确定比这个要大，假定每一个人须要3秒才能进站，那实际并发应为4人/s3s=12，固然影响因子能够根据实际状况增大！

3、根据PV计算公式：
好比一个网站，天天的PV大概1000w，根据2/8原则，咱们能够认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：
1000w80%/(93600)=246.92个/s,取经验因子3，则并发量应为：
246.923=740

4、根据TPS估计：
公式为 C = (Think time + 1)*TPS

5、根据系统用户数计算：
并发用户数 = 系统最大在线用户数的8%到12%
备注：本人目前在网上只找到了这5种，计算并发用户数的方法，其余计算方法，欢迎你们留言补充

1.业务并发用户数；2.最大并发访问数；3.系统用户数；4.同时在线用户数；
假设一个OA系统有1000用户，这是系统用户数；最高峰同时有500人在线，是“同时在线人数”，也称做“最大业务并发用户数”；500个同时使用系统用户中20%查看系统公告，不构成压力；20%填写表格（只在提交时才会请求，填写对服务器不构成压力）；40%在发呆（什么都没作）；20%用户不停从一个页面跳转另外一个页面（只有这20%对服务器产生了压力）。
说明服务器实际压力，能承受的最大并发访问数，既取决于业务并发用户数，还取决于用户的业务场景，这些能够经过对服务器日志的分析获得。
通常只须要分析出典型业务（用户经常使用，最关注的业务操做）
给出一个估算业务并发用户数的公式（测试人员通常只关心业务并发用户数）
C=nL/T
C^=C+3×(C的平方根)
C是平均的业务并发用户数、n是login session的数量、L是login session的平均长度、T是指考察的时间段长度、C^是指业务并发用户数的峰值。
该公式的得出是假设用户的login session产生符合泊松分布而估算获得。
假设OA系统有1000用户，天天400个用户发访问，每一个登陆到退出平均时间2小时，在1天时间内用户只在8小时内使用该系统。
C=400×2/8=100
C^=100+3×(100的平方根)=100+3×10=130
另外，若是知道平均每一个用户发出的请求数u，则系统吞吐量能够估算为u×C
请注意：精确估算，还要考虑用户业务操做存在必定的时间集中性（好比上班后1小时内是OA系统高峰期），采用公式计算仍然会存在误差。针对例子OA系统能够把1小时设定为考察时间的粒度，将一天8小时划分为8个区间，这样能够解决业务操做存在集中性问题，更趋于精准，误差更小。

若每个月有30000次的用户登陆系统，天天8小时工做日，每个月80%的登陆在20%的时间内完成，天天80%的业务在20%的时间内完成，计算每分钟并发量的最大值和最小值（提示：并发用户最大值按日高峰访问量的80%同时访问计算，并发用户量最小值按照日均访问量的80%计算）

解答：

提醒：首先容易出错的在于每个月、天天这两个词，必定要注意

1.每个月80%的登陆在20%的时间内完成

月总登陆次数：30000次；30000*80%=24000

每个月按30日计算（这里须要注意点，题目并无说按工做日算，暂且按30日算）：30*20%=6

获得日高峰登陆系统次数：24000/6=4000次

2.天天80%的业务在20%的时间内完成

每日平均登陆次数（按30天计算）：30000/30=1000次

天天80%的业务次数：1000*80%=800次

天天8小时计算，20%时间完成：8*20%=1.6小时

每分钟的登陆次数：800/（1.6*60）=8.3次

3.提示：并发用户最大值按日高峰访问量的80%同时访问计算，并发用户量最小值按照日均访问量的80%计算

（1）并发用户最大值按日高峰访问量的80%同时访问计算

日高峰访问量80%：4000*80%=3200次

每分钟最大并发数：3200/（1.6*60）=33.33次

（2）并发用户量最小值按照日均访问量的80%计算

每分钟最小并发数：800/（1.6*60）=8.3次

一个系统的最大并发用户数为1100，怎么能推算出该系统的支持最大用户数。
其中用户性能要求以下：支持100万注册用户性能需求分析：
一、根据用户的要求，本系统要支持100万用户，其中性能机器配置如何？高峰值是多少？带宽？等
二、若是都是采用公司的测试环境，那么本次性能应该作哪几种性能？性能评测、负载测试、强度测试？
三、怎么算出并发用户数？响应时间？性能指标
肯定：由于用户的性能需求太广，没有定到具体的数值。
那么我怎么开展后继的工做？
一、肯定采用公司测试环境，不用考虑环境问题。也就是说，客户端、服务端以及带宽等一系统均可以不用考虑，这是固定。
二、考虑此项目组之前开发过的系统性能状况，可否作为一个参考值。
解决方案：找出本项目组以并发过二个项目，其性能个项指标进行求权。
其中浏览功能：并发数为1100，平均响应时间363秒；每用户平均响应时间为0.33秒。每秒中并发3个用户。其中一系统用户已达500万，另外一系统用户为320万。而且二系统一直运行正常，但目前的二系统的服务器各为3台。能够得出一台服务器为载166万，甚至更多。（由于服务器中有求权的关系）三、100万用户，那么怎么计算出他的每小时峰值活动用户数？解决方案：采用80•20原则计算获得每小时峰值活动用户数 6.667万/小时；那么每秒中的同一功能点点击并发数应该是18.5。四、怎么得其并发数？解决方案：本系统有多少个功能点？功能点为153个；也就是本系统在高峰值时一功能将被点击1258次，每秒点击0.35次。（不考虑间隔时间）考虑之前本项目组的数值。初步设置并发数为1100，主要以浏览功能为主、其次是查询和新增。五、应该测试那种性能类型经再三考虑，三种性能都进行测试。执行性能：评测，依据性能指标肯定中的第三点，将用户的并发设置为300-350，看其状况。负载测试，以1100为起点强度测试，为15小时和24小时为准性能测试结果：发现本系统最大用户支持为1100.失败用户最高为209，响应时间为315。能够判断此系统最大并发数为1100左右。也就说此系统在一台服务器上可支持150万用户数。根据上述状况，能够得出：1100用户并发时，用户一共响应时间为315秒（即每用户平均响应时间0.005秒），其中最高产生209个失败用户，但成功用户基本上能够完成后续操做，符合现系统要求的最大稳定用户数。由此可得出本系统在新增功能点中支持最大用户并发数为1100。按照1*100比例，计算获得每小时峰值活动用户数11万/小时；采用80•20原则计算得出本系统支持注册用户数约为165万。而本系统性能需求大规模支持100万注册用户，由上述的数据咱们的系统已达到本系统性能需求。注：100万，采用80•20原则计算获得每小时峰值活动用户数6.667万/小时。

编译脚本

echo "create datadir..."
mkdir /htdata  &&  cd   /htdata
echo "install gcc pcre-devel opsenssl......"
sleep  5
yum install gcc pcre-devel openssl-devel expat-devel autoconf libtool gcc-c++
echo "wget httpd apr  apr-tuil...."
sleep  5
wget  http://mirrors.tuna.tsinghua.edu.cn/apache//httpd/httpd-2.4.39.tar.gz
wget http://mirrors.tuna.tsinghua.edu.cn/apache//apr/apr-1.7.0.tar.gz
wget http://mirrors.tuna.tsinghua.edu.cn/apache//apr/apr-util-1.6.1.tar.gz
echo "uncompress....."
ls  /htdata  | awk '{print "tar xf " $1 }' | bash 
echo "copy  pre datadir to  httpd dir..."
sleep  5
cp -r apr-1.7.0 httpd-2.4.39/srclib/apr
cp -r apr-util-1.6.1 httpd-2.4.39/srclib/apr-util
cd httpd-2.4.39/
echo "./configure  ....."
./configure --prefix=/app/httpd24 --enable-so --enable-ssl --enable-cgi --enable-rewrite --with-zlib --with-pcre --with-included-apr --enable-modules=most --enable-mpms-shared=all --with-mpm=prefork    
echo "make && install"
sleep  5
make &&  make install
echo "add  PATH"
echo 'PATH=/app/httpd24/bin:$PATH'  > /etc/profile.d/httpd24.sh
useradd -r -s /sbin/nologin apache
echo -e  "User apache \n Group apache \n"  > /app/httpd24/conf/httpd.conf
echo '/app/httpd24/bin/apachectl start'  >> /etc/rc.d/rc.local
chmod +x /etc/rc.d/rc.local
echo   "start & reboot "
sleep  5
apachectl start 
reboot