Updates from 二月, 2012 Toggle Comment Threads | 键盘快捷键

  • 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 21:46 on 2010 年 12 月 16 日 链接地址 | 回复
    Tags: , fastrpc, ,   

    From: http://blog.thinkinlamp.com/wp-trackback.php?p=538

    fastRPC: http://code.google.com/p/fastcgirpc/

     
  • bixuan 17:28 on 2010 年 11 月 23 日 链接地址 | 回复
    Tags: ,   

    [转载]多IDC数据时序问题及方法论 

    上一周在微博架构与平台安全演讲中提到多IDC及架构设计的方法,由于最近工作中经常碰到这种情况,再举一个小案例补充一下。

    Web数据访问比较好的设计模式是使用cursor方式(参考前文用Twitter的cursor方式进行Web数据分页),原理上相当于增量方式访问数据,可以极大提高访问性能。

    在单IDC场景中,如图1,系统的id是递增,假设用户上一次访问最新一条记录是1002,则本次访问最佳的方式是 get?cursor=1002,可以高效取到后面3条新记录。

    多IDC场景,看图2,假设白色背景属于Region 1,灰色背景属于Region 2, 由于两地同步有延迟,这样在Region 1中1001和1003来到时间较晚,排在本地数据1002和1004后面。假设用户上一次也是取到最新一条是1002(注意此时1001没取到,因为从外地未同步过来)。在Region 1调用 get?cursor=1002返回结果会得到什么?从数据库角度来看,访问cursor=1002 只会取到id>1002的记录,而上次未取到的1001即使已经同步过来是永远不会返回了。这样就产生了数据一致性问题,1001丢了。另外一个机房Region 2调用也产生类似问题。不同的cursor产生不同的丢失问题。

    提出这个问题后身边很多技术人员非常感兴趣,经常走在路上被拦住介绍他们突然想到的一种更巧妙的解决方法。部分思路如下
    (这里先不考虑ID递增算法如何实现,多IDC使用K-SORT方式递增也是比较容易的)

    • 例外的方式,把迟到的id都存下来
    • 补方式,把cursor往前多取一点,宁滥毋缺
    • 快照方式,最近取的记录都存下来,这样服务器内部知道这个cursor上次哪些id取了哪些没取

    大部分方法貌似都能工作,但都有问题或不完美,更重要的一点,也就是上周演讲中提到的,架构要把复杂的问题抽象简单,很多技术人员面对这个问题,并没有深层次思考这个场景的问题本质是什么,因此虽然匆匆考虑了很多复杂的解决方案,但是没有完美解决问题。

    有兴趣的朋友可以继续思考,看能否将复杂的问题抽象简单并解决?

    From: http://timyang.net/architecture/method/

     
  • bixuan 17:08 on 2010 年 11 月 23 日 链接地址 | 回复
    Tags: ,   

    [转载]微博架构与平台安全演讲稿 

    微博架构与平台安

    View more presentations from Tim Y.

     
  • bixuan 19:20 on 2009 年 12 月 21 日 链接地址 | 回复
    Tags: ganglia, xml, 插件,   

    基于ganglia为核心的监控系统设计

    至于什么是ganglia就不说了,通过ganglia可以获取一个xml格式个具体的监控数据,很详细,当然如果认为要监控的数据少了,可以自己写个插件玩玩。

    初步设计:
    1、增加IP管理的表,针对这个管理的功能可以自己定义;
    2、增加后台运行执行的脚本:判断IP是否超过一定时间没接收到数据了,然后可以设置是否报警,报警给谁等等;
    3、用C或者python写自定义的插件,以满足自己的需求;
    4、一些小细节的优化,比如:前端页面的美观、显示更多的link等等;
    还有其他可以做到的东西很多,回头再来折腾。

     
  • bixuan 22:30 on 2009 年 03 月 31 日 链接地址 | 回复
    Tags:   

    DNS管理系统 

    从去年就喊着要开发DNS管理,到今天才算完整了第1个版本,目前是Beta1.0,功能:

    1. 用户管理,支持2级的管理;
    2. 域名管理,可以添加多个域名;
    3. 记录管理,方便的添加,修改记录,同时支持单个zone的迁移;
    4. 多VIEW支持(其实就是简易上的GSLB),目前支持76个view;
    5. 权限管理,可以针对不同用户进行权限设置;
    6. 日志查看(第1版只对域名解析记录操作做日志保留,且保留最近20条)

    未来的功能:

    1. 动态更新解析记录,更灵活实现GSLB

    睡觉:)

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