已经受不了某bbs的龟速了,自己又不太可能去直接写探针插入php文件里面进行监控,毕竟是很复杂的discuz,加之昨晚在一台基本没人访问服务器上试用了听云,于是打算在这台bbs的服务器上部署听云、监测性能。
原有数据:
最高在线人数1500人的某论坛,discuz
。
原有访问时间统计大概在10-12秒左右,图中所示为调整后的响应时间。
安装听云:
-
Gentoo
系统,所以下载bin安装包。
- 不出所料,听云是无法识别到底是哪个php的,服务器安装了
php-cli
,php-cgi
,php-fpm
三个sapi,于是听云安装成了cli-php5.5
的插件。
手动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
的代码:
文件在www/source/class/helper/helper_seccheck.php
,可以看出有一个cloudip,那么根据后台功能猜测是“云IP屏蔽”之类的功能,进入后台关闭。
结果
这次直接命中要害:seccheck
的延迟直接没有,平均值也变为0.044秒。
seccheck的真面目:
结论
貌似xdebug也是可以进行这种性能调试的,以后好好研究下。
后记
第二天观察听云报告,有些访问有的时候卡在一个文件很长时间:
打开这个文件查看,发现这个问题出在:
问题出在是从discuz官方自动获取标签的功能。
嗯,应该去找站长联系取消标签功能,或者类似的。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。