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

原有数据：

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

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

安装听云：

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

1. 不出所料，听云是无法识别到底是哪个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官方自动获取标签的功能。
嗯，应该去找站长联系取消标签功能，或者类似的。