高并发下的PHP应用优化

服务器环境

1.服务器4台，4核8G，配置了SLB。
2.REDIS服务，支持1w的连接数。
3.参考参数

3.1 load avg：服务器负载情况，输入top可以看到系统当前1分钟、5分钟、15分钟内的平均load。根据服务器cpu核数计算，单台服务器4核的CPU正常的load avg是在4以下。

3.2.cpu idle：cpu空闲，高并发情况下，如果单个进程处理不够快，空闲cpu负载会迅速降低。

REDIS优化

1.复用数据走缓存，控制单个redis key的缓存时间。
2.hash域不适合塞入太多key，会引起redis服务在查询key的时候的cpu使用率升高，造成redis服务连接不上。

减少NAS操作

1.避免服务器本地写文件，日志文件记录在mongo。ES系统和seaslog服务的性能未测试到，留给各位验证。
2.php开启opcache服务，降低代码在框架中运行时，需要不断重复地加载同一文件。

服务器TCP配置更改

tcp配置可参考文章：
https://blog.youkuaiyun.com/weixin_42104231/article/details/83656839

1.time_wait：
系统中默认的time_wait值为30；

经典的4次挥手理论中，客户端请求关闭与服务端的链接（一次挥手），服务端响应请求，并发送响应报文给客户端（二次挥手），然后客户端就会有一段wait的时间，在等待服务器在上一个响应之后，把剩下的数据发完，发完数据之后服务器又会发送一个报文通知客户端（三次挥手），客户端响应告知，并发送确认报文（四次挥手）。
经过4次挥手后，链接中断。
在我们的应用中，我们的服务器作为客户端链接redis服务，那么在三次挥手之后，客户端会有30秒的时间，来等待服务器是否还有新的数据发过来，在此期间服务器会一直保持监听状态。为什么30秒呢，因为tcp包在网络中存活的最大时间为1个msl（Max Segment Lifetime），即15秒，系统默认设置的time_wait时间为2个msl，即30秒 。
现在我们将这个值改小，即服务端发送完数据后，客户端不再花很多时间去监听服务端还有没有数据传输过来。

	修改time_wait的步骤如下：
	修改/etc/sysctl.conf ：

	net.ipv4.tcp_tw_reuse = 1  #表示开启重			用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

 	net.ipv4.tcp_tw_recycle = 1   #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。net.ipv4.tcp_timestamps 开启时，net.ipv4.tcp_tw_recycle开启才能生效,。

	net.ipv4.tcp_timestamps = 1     #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

	net.ipv4.tcp_fin_timeout = 2      #用来设置保持在FIN_WAIT_2状态的时间

	保存后sysctl -p生效

2.tcp_max_tw_buckets
这个值是在time_wait达到满足数量的时候，不会去产生新的time_wait值。
优点是端口够用，减少了阻塞的产生；缺点是假设客户端端口A1与A2服务器通信结束，A1在第三次挥手结束后，A1端口没有产生time_wait的，随后A1端口被服务B占用，而此时，A2服务器又发送了新的报文过来，那么B服务就可能产生502的报错。

PHPTRACE的使用

具体可参考：https://github.com/Qihoo360/phptrace
是一款可用来追踪php运行过程的工具。
我们用了这个工具来追踪到程序运行中效率慢的部分。