已经受不了某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官方自动获取标签的功能。
嗯，应该去找站长联系取消标签功能，或者类似的。
