【软件性能测试与调优实践】web中间件的性能分析与调优

目前web中间件使用的最多的是Apache和Nginx，很多大型互联网公司都会使用这两种作为web中间件
很多编程语言在进行开发时，会将Apache或者Nginx作为其绑定的固定组件，比如：
用PHP语言进行web开发时，经常和Apache联系在一起，使得Apache称为了PHP在web开发时的一个标配
Nginx不管在作为web静态资源访问管理，或者作为动态的请求代理，性能都是非常高效
当然Nginx或者Apache有时候也会存在性能瓶颈，需要进行性能分析和调优以支持更高效的并发处理能力

Nginx的性能分析与调优

Nginx负载均衡策略的介绍与调优

在一般情况下，web中间件最大的作用就是负责对请求进行分发，也就是我们经常说的起到负载均衡的作用。当然负载均衡只是nginx的作用之一
Nginx常见的负载均衡策略一般包括轮询、指定权重(weight)、ip_hash、least_conn、fair、url_hash等六种

默认执行的策略为轮询
fair和url_hash属于第三方策略，这两种策略不是Nginx自带支持的策略，需要安装插件辅助支持

不同场景下，每一种策略的选择对系统的整体性能影响都非常大

轮询策略

Nginx的负载均衡通过配置upstream来实现请求转发。如果在upstream中没有指定其他任何的策略时，Nginx会自动执行轮询转发策略，upstream中配置每台服务器的权重都一样，会按照顺序依次转发
一个简单的upstream配置

upstream applicationServer{
	server 192.168.1.14;
	server 192.168.1.15;
}

请求会按照接收到的顺序，依次轮询转发给192.168.1.14和192.168.1.15两台服务器进行执行

Nginx能自动感知需要转发到的后端服务器是否挂掉，如果挂掉，Nginx会自动将那台挂掉的服务器从upstream中剔除

使用轮询策略时，其他非必填的辅助参数

• fail_timeout
  该参数需要和max_fails参数结合使用，用于表示在fail_timeout指定的时间内某个服务器允许重试连接的最大次数

• max_fails
  在fail_timeout参数设置的时间内最大失败次数，如果在这个时间内，所有针对该服务器的请求都失败了，Nginx就判定该服务器挂掉了

• down
  标记指定的服务器已经挂掉了，Nginx将不会再向标记为down的服务器转发任何的请求

指定权重(weight)

通过在upstream配置中给相应的服务器指定weight权重参数来实现按照权重分发请求。weight参数值的大小和请求转发比例成正比，该配置一般用于后端应用程序硬件配置差异大而导致承受的访问压力不一样的情况
配置示例

upstream applicationServer{
	server 192.168.1.14 weight=8;
	server 192.168.1.15 weight=10;
}

ip_hash

每个请求按原始访问ip的hash结果来进行请求转发
由于同一个ip的hash值肯定是不变的，这样每个固定客户端就会只访问一个后端应用程序服务器。此种配置一般用来解决多个应用程序服务器的session复制和同步的问题，因为同一个ip的请求都转发到同一台服务器的应用程序上，所以也就不会有session不同步的问题了。但这也可能导致后端应用服务器但负载不均的情况
示例配置

upstream applicationServer{
iphash;
	server 192.168.1.14;
	server 192.168.1.15;	
}

least_conn

通过在upstream配置中增加least_conn配置后，Nginx在接收到请求后会把请求转发给连接数较少的客户应用程序服务器。轮询算法是把请求平均地转发给各个后端，使它们的负载大致相同，但有些请求占用的时间很长，会导致其所在的后端负载较高，这种情况下，least_conn这种方式就可以达到更好的负载均衡效果
示例配置

upstream applicationServer{
least_conn;
	server 192.168.1.14;
	server 192.168.1.15;
}

fair

属于第三方策略
按照服务器端的响应时间来分配请求给后端应用程序服务器，响应时间端的优先分配
示例配置

upstream applicationServer{
	server 192.168.1.14;
	server 192.168.1.15;
	fair;
}

url_hash

属于第三方策略
按照访问的目标url的hash值来分配请求，使同一个url的请求转发到同一个后端应用程序服务器，请求的分发策略和ip_hash有些类似
在进行性能调优时，主要是适用对缓存命中进行调优，同一个资源（也就同一个目标url地址）多次请求，可能会到达不同的后端应用程序服务器上，会导致不必要的多次下载。使用url_hash后，可以使得同一个目标url会到达同一台后端应用程序服务器，这样可以在服务器端进行资源缓存，再次收到请求时可以直接从缓存中读取
示例配置

upstream applicationServer{
	server 192.168.1.14;
	server 192.168.1.15;
	hash $request_uri;
}

Nginx进程数的配置调优

Nginx服务启动后会包括两个重要的进程：

• master进程
  可以控制Nginx服务的启动、停止、重启、配置文件的重新加载

• worker进程
  处理用户请求信息，将收到的用户请求转发到后端应用服务器上

worker进程的个数可以在配置文件nginx.conf中进行配置

worker_processes  1;  #  Nginx配置文件中worker_processes指令后面的数值代表了Nginx启动后worker进程的个数

worker进程的数量一般建议等于CPU的核数或者CPU核数的两倍。通过指定lscpu命令获取CPU的核数信息

或者通过执行grep processor /proc/cpuinfo|wc -l 命令也可以直接获取CPU的核数

在配置完worker进程的数量后，还建议将每一个worker进程绑定到不同的CPU核上，这样可以避免出现CPU争抢
通过在nginx.conf中增加worker_cpu_affinity配置，例如将worker进程分配到4核的CPU上，可以进行配置

worker_processor    4;
worker_cpu_affinity  0001 0010 0100 1000;

Nginx时间处理模型调优

为了性能得到最优处理，Nginx的连接处理机制在不同操作系统中一般会采用不同的I/O事件模型
在linux操作系统中，一般使用epoll的I/O多路复用模型，可以使用如下配置来使用epoll事件处理模型

events {
worker_connections  1024;
user epoll;
}

• I/O多路复用的说明
  在Nginx中可以配置让一个进程处理多个I/O事件和多个调用请求，这样处理方式就像Redis中的单线程处理模式一样。redis缓存读写处理时采用的虽然是单线程，但是性能和效率是非常的高，这就是因为Redis采用了异步非阻塞I/O多路复用策略，导致资源开销很小，不需要重复去创建和释放资源，而是共用一个处理线程
  Nginx中也采用异步非阻塞I/O策略，每个worker进程会同时启动一个固定的线程，以利用epoll监听各种需要处理的事件，当有事件需要处理时，会将事件注册到epoll模型中进行处理。异步非阻塞I/O策略在处理时，线程可以不用因为某个I/O的处理耗时很长而一直导致线程阻塞等待，线程可以不用也不必等待响应，而可以继续处理其他的I/O事件。当I/O事件处理完成后，操作系统内核会通知I/O事件已经处理完成，这时线程才会去获取处理好的结果

• epoll处理模型
  epoll库是Nginx支持的高性能事件驱动模型之一
  epoll属于poll模型的一个变种，poll库创建一个集合，在每个描述符对应的结构上设置事件的类型是读事件、写事件还是异常事件，最后轮询的时候，同时检查这3种事件是否发生
  epoll和poll主要区别在于epoll不需要使用轮询的模式去检查有没有对应的事件发生，而是交给操作系统内核去负责处理，一旦有某种对应的事件发生时，内核会把发生事件的描述符列表通知给进程，这样就避免了轮询整个描述符列表
  epoll可以同时处理的I/O事件数是操作系统可以打开文件的最大数目，而且epoll库的I/O效率不随描述符数目增加而性能下降，因为它只会对操作系统内核反馈的待处理的文件描述符进行操作

Nginx客户端连接数调优

在高并发的请求调用中，连接数有时候很容易称为性能的一个瓶颈
Nginx可以通过如下方式调整Nginx的连接数

• 配置Nginx单个进程允许的客户端最大连接数
  修改Nginx中的nginx.conf配置文件

events       # 可以设置Nginx的工作模式以及连接数上限
{
	worker_connections  1024;
]

• 配置Nginx worker进程可以打开的最大文件数
  修改Nginx中的nginx.conf配置文件

worker_processes   2;
worker_rlimit_nofile  2048;    # 设置worker进程可以打开的文件数

• Linux内核的优化
  在linux操作系统的/etc/sysctl.conf配置文件中，重新配置很多linux系统的内核参数

Apache的性能分析与调优

Apache几乎运行在所有的操作系统中，支持HTTP、SSL、Socket、FastCGI、SSO、负载均衡、服务器代理等功能模块

Apache的工作模式和进程数调优

Apache的工作模式主要是指Apache在运行时内存分配、CPU、进程以及线程的使用管理和请求任务的调度等
Apache比较稳定的工作模式有prefork模式、worker模式、event模式，默认使用的是prefork模式（一般可以在编译安装Apache时通过参数–with-mpm来指定安装后使用的工作模式）

perfork模式

采用非线程型的预派生方式来处理请求
在工作时使用多进程，每个进程在同一个固定的时间只单独处理一个连接，这种方式效率高，但由于是多进程的方式，所以内存使用比较大
perfork的处理过程是单进程和单线程，不存在线程安全的问题，但是在高并发请求的场景，perfork模式会将请求放进队列中，一直等到有可用子进程请求才会被处理，也很容易导致请求队列积压

worker模式

使用了多进程和多线程相结合的混合模式来处理请求
worker模式是主进程首先会派生出一批子进程，但和perfork模式不同的是，worker模式下每个子进程都会创建多个线程，每个请求会分配给一个不同的线程处理。worker模式高并发处理能力更强，但是需要考虑线程安全问题

event模式

与worker模式有些类似，在event模式中，会有一些专门的线程来承担管理和分配线程的工作，通过这种方法解决来HTTP请求keep-alive长连接的时候占用线程资源被浪费的畏难而退
因为有一些专门的线程用来管理这些keep-alive类型的工作线程，当有真实请求过来时，将请求传递给服务器端可用的工作线程进行处理，处理完毕后又允许其释放资源

Apache的KeepAlive调优

HTTP请求中开启KeepAlive选项相当于长连接的作用，多次HTTP请求共用一个TCP连接来完成，这样可以节约网络和系统资源
一般开启KeepAlive适用的场景

• 如果有较多的静态资源（如JS、CSS、图片等）需要访问，则建议开启长连接
• 如果并发请求非常大，频繁地出现连接建立和连接关闭，则建议开启长连接

如果出现这种请求可以考虑关闭KeepAlive选项：
服务器内存较少并且存在大量的动态请求或者文件访问，建议关闭长连接以节省系统内存和提高Apache访问的稳定性

在Apache中开启KeepAlive选项的方式是通过 vi httpd.conf来增加或修改httpd.conf中的配置

KeepAlive On
MaxKeepAliveRequests  100
KeepAlivetimeout  15