0%

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

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

一、背景

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

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

二、处理过程

  1. 现象复现,开发机1是正常的(虽然也消耗了1s多),开发机2是测试妹子反应慢的

    • 开发机1切换配置 正常切换
    • 开发机2切换配置 超级慢切换
  2. 处理过程

    • ①登录开发机2,查看系统资源是否达到上限,暂未发现异常 top df
    • ②查看php-fpm慢日志,问题其实已经很明显,正常只需要看一下方法的调用链就能追踪到具体哪一步一起的,推荐PHP性能测试扩展xhprof,碍于没有权限,只能继续别的方式。
    1
    2
    3
    4
    5
    6
    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行代码,遂重新复制了一个类文件,里面只包含一个方法,重试依然不行
    • ⑤看代码也没有问题,原有的逻辑一直没动,看到里面有个循环读取目录的逻辑,遂想着是不是配置文件本身有问题
    • ⑥查看配置文件,尼玛,果然有人多创建了一层目录,代码一直在循环遍历目录。。。

三、

  1. 监控php-fpm的状态

    • 修改对应的vhost,在server内加入以下配置
      1
      2
      3
      4
      5
      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情况,
    • 结果说明
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    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 最大的子进程达到
  2. 按上面的步骤弄完并看不出来什么问题,查看对应的日志,报了一堆upstream timed out (60: Operation timed out)

  3. 在server内加入以下配置

1
2
3
4
5
6
7
8
9
10
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;
  1. 重启ngix,响应速度并没有快多少,只是不再报upstream timed out (60: Operation timed out)

四、参考

  1. 参考一
  2. 参考二