Aggregate checks do not require any agent running on a host being monitored. Zabbix server collects aggregate information by doing direct database queries.

可以实现对组的数据统计和分析，太好了。

昨天我在Google Ventures为他们的一些投资公司做了个研讨会。我不知道听众会有多少关于性能优化的背景知识，因此我从2007年的第一个演示开始，回顾了几乎跟性能优化相关的所有内容，真的是很怀旧啊。话说距离我开始谈论《高性能网站建设指南》的最佳实践已经很多年了，我重新审视了这些早期的提示，比如减少HTTP请求，和添加Expires头，还有压缩组件。

不过我还需要回顾得更远一些，想到在还没有Velocity和WPO之前，我或许还得澄清一下为什么我会如此关注前端性能。我找到了当时包含性能黄金法则的幻灯片：

80-90%的最终用户响应时间都花在前端上。
从这里开始。

还有一些其他相关的幻灯片展示了一些流行的网站分别花在后端和前端的时间，但是数据已经很旧并且很有限了，因此我决定更新一下，下面是我的成果。

首先是一个瀑布图，它展示了前后端的划分。这个瀑布图是LinkedIn的。这里“后端”的时间是指从服务器返回第一个字节到客户端所花费的时间。它通常包含大部分的后端处理：数据库查询、远程web服务调用、拼接HTML等等。其余的是“前端”的时间，它包含了显而易见的前端阶段，诸如执行JavaScript代码以及渲染页面等。它同时也包含了下载页面上所有相关资源的时间。我把这些划分到前端时间里是因为，有许多切实可行的办法可以减少这个时间，比如 异步加载脚本，合并脚本和样式表以及域名分散（即通过多个域名实现并行下载的策略  ——译者注）等。

对于排名前十位的网站分析结果显示，平均在前端花费的时间占比为76%，略低于黄金法则中提出的80-90%的值。不过别忘了，这些网站的前端都经过了高度的优化，并且其中两个是载入资源非常少的搜索页面（而不是结果页面）。

对于排名10000左右的10个网站进行的分析，可以得到一个更典型的视图。平均在前端花费的时间占比为92%，高于排名前10的76%，甚至高于黄金法则中建议的80-90%。

为了使与会者接受这个法则，我展示了他们自己网站的前后端花费时间占比，得到的结果为前端占比84%。这有助于使他们的认可我的理论，即前端的性能才是最难最有挑战的，也是最应该给予关注的。

后来我想起来我在HTTP Archive上还有关于网站耗时的信息。不过我一般不展示这些信息，因为我认为真正的用户度量应该更准确一些，不过我计算了被抓取到的50000个网站的前后端耗时占比，结果前端占比为87%。

能够获取这些比2007年更新的信息来验证性能黄金法则真是太好了，而且它也显示了前端性能优化越来越受重视了。如果你担心可用性和可扩展性，那就关注一下后端。但是如果你担心载入网站时用户等待的时间太久，那么关注前端才是王道。

FROM：http://44ux.com/index.php/2012/02/the-performance-golden-rule/

Jakob Nielsen是web可用性领域知名且备受推崇的专家，下面引用的内容论述了“足够快”的问题：

基于Web应用的响应时间准则和其他应用一样。37年来这些准则毫无变化，所以它们也不太可能因新技术的出现而发生改变。

0.1秒：用户直接操作UI中对象的感觉极限。比如，从用户选择表格中的一列到该列高亮或向用户反馈已被选择的时间间隔。理想情况下，它也是对列进行排序的响应时间——这种情况下用户会感到他们正在给表格排序。

1秒：用户随意地在计算机指令空间进行操作而无需过度等待的感觉极限。0.2~1.0秒的延迟意味着会被用户注意到，因此感觉到计算机处于对指令的“处理中”，这有别于直接响应用户行为的指令。例如：如果根据被选择的列对表格进行排序无法在0.1秒内完成，那么必须在1秒内完成，否则用户将感觉到UI变得缓慢且在执行任务中失去“流畅（flow）”的体验。超过1秒的延迟要提示用户计算机正在解决这个问题，例如改变光标的形态。

10秒：用户专注于任务的极限。超过10秒的任何操作都需要一个百分比完成指示器，以及一个方便用户中断操作且有清晰标识的方法。假设用户遭遇超过10秒延迟后才返回到原UI的情况，他们将需要重新适应。在用户的工作中，超过10秒的延迟仅在自然中断时可以接受，比如切换任务时。

1、nginx+php-cgi fpm
100000 fetches, 100 max parallel, 2e+06 bytes, in 39.5206 seconds
20 mean bytes/connection
2530.33 fetches/sec, 50606.6 bytes/sec
msecs/connect: 0.538099 mean, 3000.11 max, 0.106 min
msecs/first-response: 38.9175 mean, 402.378 max, 0.313 min
HTTP response codes:
code 200 — 100000

2、lighttpd+php-cgi fpm
100000 fetches, 100 max parallel, 2e+06 bytes, in 15.6593 seconds
20 mean bytes/connection
6385.99 fetches/sec, 127720 bytes/sec
msecs/connect: 3.78652 mean, 3001.08 max, 0.105 min
msecs/first-response: 9.88036 mean, 229.16 max, 0.495 min
HTTP response codes:
code 200 — 100000

详细见：这里

lsof|grep REG|awk '{if ($7 > 0) print $7, $9, $10}'|sort -rn|head -n 10

查看文件最大的10个文件。

如果看到：(deleted)，说明文件已经被删，但是句柄没释放。

安装php-handlersocket一开始还遇到了点小问题，说找不到-Ihsclient的库文件，估计是我安装HandlerSocket-Plugin的时候指定了prefix，而在编译php-handlersocet的时候没加环境导致的，后来为了偷懒，就直接安装到/usr/local了。

wegt -c http://php-handlersocket.googlecode.com/files/php-handlersocket-0.0.7.tar.gz
tar zxvf php-handlersocket-0.0.7.tar.gz
cd php-handlersocket
PREFIX=/opt/app
$PREFIX/php5-fastcgi/bin/phpize
./configure --with-handlersocket \
--with-handlersocket-includedir=$PREFIX/HandlerSocket-Plugin/include/handlersocket \
--with-php-config=$PREFIX/php5-fastcgi/bin/php-config
make && make install
cd ..

然后将extension=”handlersocket.so”加到php,ini配置即可。

原因是：表结构出现错误。

解决方法：
1、停止mysql；
2、在其他的机器上重该表，
3、将t_monitor_client.frm复制到故障机器上，
4、启动mysql，
5、检查，没问题就成功了。