最新发布 RSS Toggle Comment Threads | 键盘快捷键

  • bixuan 22:36 on 2012 年 03 月 25 日 链接地址 | 回复
    Tags: 苹果   

    用有效成分来看这些东西,到底准不准哪?就像是有两种水果是蛮伤身的啦,一种是苹果,一种是草莓。它们的成分都很营养、都很好啊,可是它们是一种没有子房、直接从花托长成水果的东西,所以它在生长过程里面,就是缺了一段气。而少了那些气,就会变成:你吃它的时候,你吃苹果一口,苹果也吃你一口──它会吃掉你的功力。中国历代本草书,你去查苹果(林檎),就会发现:再也没有水果比它更坏了,久服会「束百脉」、「细百脉」、「闭百脉」,一身功力尽失,简直就是武侠小说中的「十香软筋散」,难怪西洋人的圣经里面说太古不死人亚当、夏娃吃了这玩艺儿就变成会老会死了。可是它成分上一点问题都没有,好得不得了啊!那,这要怎么检证?就是,你们都去吃一年苹果,然后再去把脉,就会发现:怎么脉弱了那么多!婴儿时代被长期喂过苹果泥的人,二十八岁都还把得出来这个人的脉特别细弱。就像这样,很多东西没办法用化学成分论是非,因为很多对身体很有破坏力的东西,化学成分都是非常健康的。

     
  • bixuan 13:37 on 2012 年 03 月 25 日 链接地址 | 回复
    Tags:   

    zabbix Aggregated checks

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

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

     
  • bixuan 16:13 on 2012 年 02 月 11 日 链接地址 | 回复
    Tags: , 性能优化   

    性能黄金法则 

    原文地址:http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/

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

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

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

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

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

    Golden waterfall

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

    Golden top10

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

    Golden 9990

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

    Golden startups

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

    Top50ksite

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

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

     
  • bixuan 10:35 on 2011 年 11 月 11 日 链接地址 | 回复
    Tags: LRU, 命中率, 度量指标,   

    跟踪任何缓存软件最重要的度量指标是:
    1、缓存命中率
    2、总请求率
    3、对象平均大小
    4、LRU参考时间(当使用LRU方式时)

     
  • bixuan 11:13 on 2011 年 11 月 10 日 链接地址 | 回复
    Tags: , 准则, 响应延迟,   

    WEB访问怎么样才算足够快?

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

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

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

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

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

     
  • bixuan 10:45 on 2011 年 11 月 10 日 链接地址 | 回复
    Tags: ,   

    新创建了:运维架构师交流QQ群02(127858917),欢迎加入~

     
  • bixuan 22:17 on 2011 年 10 月 18 日 链接地址 | 回复  

    换了个皮肤,hoho

     
  • bixuan 09:25 on 2011 年 06 月 28 日 链接地址 | 回复  

    域名又到期了,NND,咋不通知我呢~~

     
  • bixuan 13:37 on 2011 年 05 月 04 日 链接地址 | 回复  

    十二生肖各有缺失:鼠无睛(畏光),牛无牙,虎无项,兔无唇,龙无耳,蛇无足,马无齿,羊无瞳(所以天气一暗就得赶快回家,不然会找不到路),猴无腮,鸡无肾(大小便一起排),狗无脾(消化道系统不健全,需要吃其他动物的排泄物,以补其不足,所以狗改不了吃屎),猪无筋(抓猪时可从尾巴抓就好,因为中间无大筋不会回过头来咬人一口)

     
  • bixuan 18:16 on 2011 年 04 月 22 日 链接地址 | 回复  

    晚上公司电影协会组织看《里约大冒险》,太给力了,哈哈~

     
  • bixuan 17:57 on 2011 年 04 月 22 日 链接地址 | 回复  

    身体好!生活好!工作好!这是对兄弟们的要求,也是部门的期望~

     
  • bixuan 23:49 on 2011 年 03 月 29 日 链接地址 | 回复
    Tags: , ,   

    刚做了2个测试:

    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

     
  • bixuan 11:35 on 2011 年 03 月 24 日 链接地址 | 回复
    Tags:   

    最近加上了网卡丢包的监控,发现BCM5709 驱动:1.9.20d,经常有丢包的报警,比例很大。FT..

     
  • bixuan 20:36 on 2011 年 03 月 09 日 链接地址 | 回复
    Tags:   

    zabbix里如何创建proxy节点?

    详细见:这里

     
  • bixuan 10:54 on 2011 年 03 月 06 日 链接地址 | 回复
    Tags: faq   

    大家有啥好问题,可以去http://faq.ourlinux.net/

     
c
写新的
j
下一篇文章/下一个回复
k
前一篇文章/以前的回复
r
回复
e
编辑
o
显示/隐藏 回复
t
回到顶部
l
go to login
h
show/hide help
esc
取消