php7应用性能提升

php的优化有这么几个方向

• Nginx和Apache
• HTTP服务器性能优化
• 内容分发网络CDN
• js/css优化
• 全页面缓存

Nginx和Apache

Apache

主要时灵活、广泛支持、模块方式等有点。因为apache实在进程内部解析大多数脚本语言的，所以没有软件间通信的开销。apache处理请求的模式有三种：prefork模式（线程创建进程）、worker模式（进程创建线程）、事件驱动模式（与worker模式类似，但这种模式会为连接保持创建专用线程，活动请求使用另外创建的线程），因此它能提供更好的灵活度。每一个请求都会由一个线程或进程处理，所以apache在处理请求时开销很大。当它在高并发场景的时候，其性能低下的问题便会凸显。

Nginx

它提供了异步、事件驱动、非阻塞请求处理。由于请求异步处理，所以nginx不必等待每个请求完成，避免锁住资源。

Nginx创建许多工作进程，每个工作进程可以处理数千个连接，因此可以使用很少的进程来承载高并发流量。

nginx没有内置任何解释型语言，如此，nginx便可以专注于处理请求的接收与相应。而具体解析脚本语言的进程则在nginx之外。

通常我们认为nginx要快于apache，但在一些场景下，例如静态资源下，apache也有自己的优势。在构建高性能服务器时，apache并不是问题所在，php才是真正的瓶颈。

HTTP SERVER优化

缓存静态文件

apache

在apache中缓存静态内容

    Header set Cache-Control "max-age=604800, publilc"

上边的内容需要被配置在.htaccess文件中，使用apache的FilesMatch命令来匹配相应的文件的扩展名。如果文件被匹配到，apache将添加头信息，以标识这类文件可以被用户端设备缓存７天，浏览器发现这样的头信息后便会缓存文件，在这个例子中浏览器会缓存７天。

nginx

Location ~* .(ico|jpg|jpeg|png|gif|css|js|woff)$ {
    Expires 7d;
}

nginx同样会在匹配到的相应静态文件时添加对应的头信息。

HTTP持久链接（HTTP Keep-alive）

表示一条TCP/IP链接上承载着多个上下行请求。相对于传统的单链接模式（一次请求需要创建一条单独的ＢＳ链接的模式）而言，HTTP Keep-alive技术有着大幅度的性能提升。优点：

• CPU和内存的负载会减轻。因为同一时刻打开的TCP链接变少了，后续请求和响应无需打开新链接，可以继续给予这些TCP链接发送上下行数据
• 当TCP链接建立后，请求的等待时间将会减少。TCP建立链接时的三次握手发生在客户端与服务端之间。当握手成功，一条TCP链接就被建立起来。在Keep alive模式下，握手环节是一次性的，即在链接建立的时候便会发生。建立链接后发生的数据传递不产生握手环节，这部分的开销将会被优化，因此可以有效提升请求上下行数据的可能。
• 网络阻塞情况轻。因为在同一时刻只会有少数的链接保持着。

不足：许多服务器有并发数的限制，当并发上升到一定程度时，程序性能将大幅下降。为了解决这个问题，设置链接超时非常有必要。设置以后，超过设定时间的链接将被自动关闭。

apache

开启Keep alive有两种方式，分别时修改.htaccess和修改apache配置文件

.htaccess

    Header set Connection keep-alive

配置文件，三个选项都需要修改

KeepAlive    On
MaxKeepAliveRequests    100
KeepAliveTimeout    100

MaxKeepAliveRequests限制了keep-alive在同一时刻的最大连接数。１００时默认配置，可以自行修改。如果设置为０，apache将不对keep-alive的连接数进行限制。

KeepAliveTimeout通常设置为１００秒，如果对于同一长连接，apache等了１００秒还未收到下一条请求，便会主动断开。

nginx

HTTP请求的keep-alive是由nginx的http_core模块支持的，默认情况下是开启的。

keepalive_requests    100
keepalive_timeout    100

keepalive_requests定义了单个客户端在一条长连接链路上可以同时发起的请求数，keepalive_timeout定义了长连接的超时时间，超过了这个时间后，nginx会断开长连接。

GZIP压缩

apache

依然是修改.htaccess

    SetOutputFilter DEFALTE
    #添加需要进行过滤的文件类型
    AddOutputFilterByType DEFALTE text/html text/plain text/xml text/css text/javascript application/javascript

    #不压缩图片
    setEnvIfNoCase Request_URI \.(?:gif|jpe?g|png) $ no-gzip dont-vary

上述配置中，apache deflate模块开启压缩，通过配置文件类型过滤器，对.html、.xml、.css、.js等文件进行内容输出前的压缩，这里没有设置图片的压缩处理，因为压缩后的图片质量会受到很大影响。

nginx

gzip on;
gzip_vary on;
gzip_types text/plain text/xml text/css text/javascript application/javascript;
gzip_com_level 4;

gzip开启后，之后的gzip_vary on将会启用varying头。gzip_com_level表明压缩等级，此处的值最好斟酌斟酌，不宜太高，取值区间是１－９，建议设置中间值。

PHP独立部署服务

apache是以mod_php模块的方式加载php的。在这种方式下，apache和php耦合的很紧，所有请求都会由apache模块处理，这会非常消耗机器的硬件资源。我们可以让php-fpm和apache结合，让它们都独立部署，通过fastcgi协议相互传递数据，这样apache只需要关注http请求连接即可，php进程则由php-fpm创建与维护。

关闭不用的模块

筛选技巧：先将所有的模块禁用并重启服务器，然后逐个开启并检查应用程序是否运行正常

apache

获得加载的所有模块的列表

apachectl -M

nginx

列出开启的模块

nginx -V

通常情况下，nginx仅开启了所需的模块进行工作

WEB服务器资源

服务器最大的问题当属ram了

nginx

nginx提供了两个变量worker_processes、worker_connections来适应资源情况，worker+processes设置决定着可以有多少nginx进程被运行。一般一个进程运行在一个cpu上时比较合适的。worker_connections配置决定了这一个进程中同时可以处理的链接数。这里的配置取决于物理核数。

ulimit -n

执行这个命令后显示的数值，就可以作为worker_connections配置的设置值。

内容分发网络（CDN）

CSS与JS优化

• 合并
• 缩小

全页缓存

如果不经常更改，可以根据情况修改后清除缓存

Varnish（web应用加速器）

负载均衡（LB）

是指根据每个web服务器的负载情况，将外网流量以一定的规则分发给web服务器。

对于负载均衡，可以使用广泛运用的HAProxy。它会检查每个web服务器的运行状况，如果web服务器关闭，它会自动将此web服务器的流量重定向到其他可用的web服务器上，为此，只有LB会监听８０端口。

我们不想将外部的ssl请求传递到web服务器，那样会加重web服务器的负载，因此需要在HAProxy服务器上终结SSL。当LB收到带有ＳＳＬ的请求时候，将转换ＳＳＬ请求并向其中的一个web服务器发送正常请求。当HAProxy接收到相应时，它将加密相应并将其发送回客户端。这样就不会让两个web服务器同事进行ssl加密/解密，只有一个LB在做这件事。

HAProxy负载均衡

安装

apt install haproxy

使用说明

准备三台服务器

• 首先是一台安装了HAProxy的服务器，称之为LB。假定ip为111.111.111.1。这台LB监听８０端口，并且所有的http请求将会落到这台服务器上。实际上这台机器此时就是所有请求的承载服务器。时最前端的机器。
• 其次需要一个web服务器，称之为web1，它安装了nginx、php7、mysql，ip为111.111.111.2。这台机器不需要监听８０，我们让他监听９９９９
• 最后一台服务器，称之为web2，环境同web1一致。ip为111.111.111.3，并且也监听９９９９．

web1与web2被称为后端服务器，在这里先配置LB服务器的监听８０端口，打开haproxy.cfg配置文件，一般位于/etc/haproxy目录下，添加配置：

frontend http
bind *:80
mode http
default_backend web-backends

上边配置了HAProxy监听８０端口，来源ip为所有ip地址。接下来配置后端服务器，在最后加入

backend web-backend
mode http
balance roundrobin
option forwardfor
server web1 111.111.111.2:9999 check
server web2 111.111.111.3:9999 check

后端的引用名是web-backend，它也在前段配置中使用。在每个web服务器的定义结束时都是用check配置项，告诉HAProxy检查服务器的运行状况，之后重启haproxy

service haproxy restart

现在，在浏览器中输入LB服务器的ip或主机名，web应用程序页面将从web1或web2获取数据并显示出来。

停用任意一个web服务器，然后重新加载页面，应用仍可以工作，因为haproxy自动检测到其中一个web服务器已经关闭，并将流量重定向到第二个服务器中。

haproxy还提供了一个通过浏览器查看stats页面，该页面可以显示关于LB和所有后端的完整状态信息。要启用stats，需要修改haproxy.cfg：

listen stats *:1434
stats enable
stats uri /haproxy-stats
stats auth phpuser:password

stats服务运行在1434端口上，这个端口可以任意配置，uri信息也可以任意设置。auth信息用于基本的web验证，可以随意设置，设置后请保存并重启haproxy，就可以进入stats页面。

最后，要使用haproxy转换SSL也很简单，添加SSL绑定443端口并且制定SSL证书的位置。打开haproxy.cfg：

frontend http
bind *:80
bind *:443 ssl crt /etc/ssl/www.xxx.crt    #加入这一行
mode http
default_backend web-backends

重启haproxy，此时haproxy开始监听443，当SSL请求发送到HAProxy时，会在内部做好转换，所以https请求不会被发送到后端服务器。这样，SSL加密/解密环节就可以从web服务器中删除，并且仅由haproxy服务器管理。由于SSL在HAProxy服务器处转换，因此web服务器无需再监听４４３端口，因为接收到的请求都是来自HAProxy的传统http请求。