1

已经受不了某bbs的龟速了,自己又不太可能去直接写探针插入php文件里面进行监控,毕竟是很复杂的discuz,加之昨晚在一台基本没人访问服务器上试用了听云,于是打算在这台bbs的服务器上部署听云、监测性能。

原有数据:

最高在线人数1500人的某论坛,discuz

clipboard.png

原有访问时间统计大概在10-12秒左右,图中所示为调整后的响应时间。

安装听云:

  1. Gentoo系统,所以下载bin安装包。

clipboard.png

  1. 不出所料,听云是无法识别到底是哪个php的,服务器安装了php-cliphp-cgiphp-fpm三个sapi,于是听云安装成了cli-php5.5的插件。

clipboard.png

手动
mv /etc/php/cli-php5.5/ext-active/networkbench.ini mv /etc/php/fpm-php5.5/ext-active/
nano /etc/php/fpm-php5.5/ext-active/networkbench.ini,修改application name
/etc/init.d/php-fpm restart

等待测试报告:

图片描述

关键过程1

图片描述

这里有一个SQL查询瓶颈,在pre_home_notification表,于是进入查询。
数据表大约400M大,select count查询大约在4.3S左右,于是肯定这里需要有问题。
查询网络,搜到相关资料:“home_notification表会有定时任务进行清空。”

于是grep -r home_no www,搜到www/source/include/cron/cron_cleannotification.php文件,进入discuz后台查询,没有这个文件,手动添加这个计划任务,执行后,pre_home_notification表瞬间变为4M大小。也不再收到相关的关键过程记录。

关键过程2

解决1后,仍旧有很大的延迟,而且响应似乎完全没有改变,于是继续查询关键过程,发现关键过程2:

图片描述

是在seccheck中调用两次fgets,直接导致网站访问速度慢。
搜索seccheck的代码:

clipboard.png

文件在www/source/class/helper/helper_seccheck.php,可以看出有一个cloudip,那么根据后台功能猜测是“云IP屏蔽”之类的功能,进入后台关闭。

结果

这次直接命中要害:
seccheck的延迟直接没有,平均值也变为0.044秒。

图片描述

seccheck的真面目:

clipboard.png

结论

貌似xdebug也是可以进行这种性能调试的,以后好好研究下。

后记

第二天观察听云报告,有些访问有的时候卡在一个文件很长时间:
图片描述

打开这个文件查看,发现这个问题出在:
图片描述

问题出在是从discuz官方自动获取标签的功能。
嗯,应该去找站长联系取消标签功能,或者类似的。


大舒
7k 声望815 粉丝

define TRUE FALSE