记一次排查web响应超级慢的过程

游戏策划是一个计划者，他需要做的事情是在内容还没有实现之前，先做好计划，通俗点讲也可以称为画饼，或者专业点讲类似于web端的产品经理。

一、背景

博主现就职于一家游戏公司，主要工作是用PHP写业务类的接口。众所周知PHP是面向短连接的，而游戏一般客户端和服务端建立长连接，后端只用PHP肯定是不行的，具体怎么实现的或者说整个游戏的架构在此就不多说了。一般的开发过程就是运营或策划提出需求，带着正式的需求文档，然后叫上各个部门的相关同学(美术、前端、后端、测试、运营等)去会议室听策划讲解整个文档，讲解结束后要评估各个部门的开发排期，接下来就按开发排期就行就OK了。

一般来说后端拿到需求就可以进行了，前提是策划已经把配表准备好。配表分为了研发、测试、预发布、正式等几种，整个功能开发过程中要不断的切换配置。后端用web接口的形式实现了切换配置，输入不同的参数切换不同的配表。本来一切都进行的好好的，某天测试的妹子说web接口切换配置好慢，让帮忙处理下，终于进入到今天的主题了。

二、处理过程

现象复现，开发机1是正常的(虽然也消耗了1s多)，开发机2是测试妹子反应慢的
- 开发机1切换配置
- 开发机2切换配置

处理过程

①登录开发机2，查看系统资源是否达到上限，暂未发现异常
②查看php-fpm慢日志，问题其实已经很明显，正常只需要看一下方法的调用链就能追踪到具体哪一步一起的，推荐PHP性能测试扩展xhprof，碍于没有权限，只能继续别的方式。

script_filename = /you_know/secret/path/index.php
[0x00007fceeae13b20] exec() /you_know/secret/path/app/controller/AAA.php:436
[0x00007fceeae137d0] clearConfig() /you_know/secret/path/inc/coreBBB:104
[0x00007fceeae13230] dispatch() /you_know/secret/path/app/util/CCC.php:140
[0x00007fceeae130c0] run() /you_know/secret/path/index.php:4
[0x00007fceeae13030] /you_know/secret/path/index.php() unknown:0

③查看nginx日志(access.log和error.log)，暂未发现异常
④猜测是php文件过大导致，一个类文件写了9783行代码，遂重新复制了一个类文件，里面只包含一个方法，重试依然不行
⑤看代码也没有问题，原有的逻辑一直没动，看到里面有个循环读取目录的逻辑，遂想着是不是配置文件本身有问题
⑥查看配置文件，尼玛，果然有人多创建了一层目录，代码一直在循环遍历目录。。。

三、

监控php-fpm的状态

修改对应的vhost，在server内加入以下配置

location ~ ^/status$ {
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
}

修改php-fpm.conf，打开以下选项：

1	pm.status_path = /status

访问http://域名/status以查看当前的php情况，
结果说明

pool: www php运行的组
process manager: dynamic php-fpm运行的方式
start time: 04/Jun/2012:16:05:32 +0800 开始时间
start since: 5932
accepted conn: 65678 接受链接
listen queue: 0 监听队列
max listen queue: 1 最大监听队列
listen queue len: 128 监听队列len
idle processes: 82 空闲进程
active processes: 4 活动进程
total processes: 86 总进程
max active processes: 25 最大活动进程
max children reached: 0 最大的子进程达到

按上面的步骤弄完并看不出来什么问题，查看对应的日志，报了一堆upstream timed out (60: Operation timed out)
在server内加入以下配置

large_client_header_buffers 4 16k;
client_max_body_size 30m;
client_body_buffer_size 128k;
fastcgi_connect_timeout 300;
fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers   4 32k;
fastcgi_busy_buffers_size 64k;
fastcgi_temp_file_write_size 64k;

重启ngix，响应速度并没有快多少，只是不再报upstream timed out (60: Operation timed out)了

一、背景

二、处理过程

三、

四、参考