Tagged: Web性能 RSS

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

    性能黄金法则 

    原文地址: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 20:41 on 2008 年 10 月 01 日 链接地址 | 回复
    Tags: ftp, Web性能, , , , 性能监控, 成本效率, 有效性   

    四、性能监控 

    四.性能监控

    优化Web站点的首要任务就是对该站点进行监控,以便了解其模式和趋势。从监控中可以获知监控是否有助于站点。而且为监控所编写的脚本也可以用于负载测试。

     

    性能参数

    每个计算机系统都有4个传统的参数:

    延迟

    吞吐量

    利用率

    效率

    优化系统性能就是要减少延迟、增加其他3个参数的值。尽管这个定义很直观,但优化本身并不直观,因为这些参数彼此之间可以互相消长,而且它们会随时间、服务内容种类已经许多其他环境改变而改变。另外,对某个机构的目标来说,有些性能参数比其他参数重要。

     

    延迟和吞吐量

    延迟:是指请求与开始看到结果直接的间隔时间。有人选择延迟定义为开始请求和完成该请求直接的时间。

    延迟的单位是时间

     

    吞吐量:是指单位时间内能够处理的传输量。

    计算吞吐量的简单方法:累加一段时间内的传输量,然后再将其除以这段的时间。但这样计算可能会产生正确的结果,也容易误导人,因为它忽略了在样本时间内传输速度的变化。最好是采用:每个采用点相除,然后再累加算平均值。

     

    度量网络的延迟

    注意这里考虑的是网络延迟,不是应用程序的延迟(应用程序的延迟是指运行在网络服务器上的应用程序本身从开始到返回结果需要花费的时间)。

     

    因特网大部分延迟可能是路由器的存储和转发能力决定的。路由器接收一个进入的数据包,并将它放在一个缓冲区里,查看其报头信息,然后决定该数据包下一步将发往何处。即时已经决定发往何处,通常路由器仍然需要等待下一个时隙用户该数据包的发送,于是数据包的延迟在很大程度上取决于Web服务器和用户直接的路由跳数的数目

    也就是说,路由跳数的数目(hops)直接决定了网络的延迟

    那么利用traceroute功能就可以查到上文提到的hops,也可以使用mtr,mtr是结果和traceroute和ping的功能。

    Hops越少约好。

    Ping的延迟在50ms左右比较理想,超过100ms就不太理想了。

     

    2.1 度量网络延迟和吞吐量

    度量延迟和吞吐量最简单的方法是:弄清楚浏览器的高速缓存区的大小和从服务器获得一个特定页面所花的时间。可以使用lynx或者curl命令来获取相关数据。

    比如:time lynx -source http://www.51.com/ > /dev/null,这种方法也可以认为是Web性能监控的stopwatch方法。

     

    使用FTP

    另一个度量网络吞吐量的方法是,利用FTP在本机和某个远程系统之间来回传输文件。但是使用FTP也有个不足,因为传输文件如果涉及到磁盘操作,那么这样做也是不准确的。

    取消任何可能FTP传输引起的访问磁盘的请求。

    必须利用大文件,因为每次小文件的创建都需要一个磁盘访问。

    不过,可以利用某些版本ftp的将结果输出到/dev/null来达成结果。

    ftp> get bigfile > /dev/null

     

    其实用wget、curl等命令也是一样的,都是基于TCP的传输。但是不能清楚的区分网络性能和服务器性能。

     

    以上也可以写成脚本来记录一段时间的运行情况,这样获得的结果会准确。

     

    利用率

    简单地说,利用率就是实际使用某组件的容量和该组件本身容量的百分比。数学表达式:

    利用率 = 

    为了充分利用所花的钱,都希望组件的利用率为100%,但是实际上并不必须如此。因为当利用率太高时就会出现很大的延迟。就经验而言,许多组件在利用率约为70%时性能最好。

    perfmeter工具为监控系统利用率提供了一种很好的图形界面。

    有效性

    有效性 = (作为比较组件的一个基本方面是有用的,但在其他方面并没有多大用处,因为它仅仅是由其他两个性能参数相除得的结果)

    一种更有用的有效性度量是计算单位开销获得的性能,这通常叫成本效率(cost efficiency)。

    优化性能就是增加成本效率的艺术,即充分利用所花的每一分钱。实际上,因特网本身所具有的流行性就说明了这样一个事实。比如:email的延迟吞吐量比传统的邮递要快,成本低。

     

    成本效率(cost efficiency)= 单位开销所得的性能

     

    使用脚本监控Web性能

    面对的庞大的Web数据,如果手动来监控Web性能显然是不可能的,所以这里势必促使我们使用脚本自动来实现,不然perl,python,php,shell等工具。

    这里的监控是自动模拟用户登陆的行为,然后记录下各个操作点时间。

    通过监控获取日志,然后对日志进行分析,这样就可以得出相关的报表。当然日志也可以保存在数据库里。

     

    注意:过渡的监控对Web站点的运行同样有害!

     

     

     

    关键性建议

    不要太依赖基准,除非这些基准与你实际想做的密切相关。

    不仅监控服务器的负载,而且监控实际的Web性能,并作记录。

    不要进行过多的监控,否则你将成为制造问题的一份子。

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