Rails3中的性能分析方法

标签: 测试工具 rails ruby web | 发表时间:2012-04-28 22:18 | 作者:博一
出处:http://qa.taobao.com

(转帖请注明出处: http://qa.taobao.com/?p=15025)

性能分析是Web应用开发中非常重要的一个环节,相比访问缓慢的站点,访问快速的站点拥有更好的用户体验,帮助用户节省更多时间,带来更多的用户访问。

作为当前十分流行的Web框架, rubyonrails当然也提供很多方式进行性能分析。

几种常见的方式

Rails日志文件

Rails日志文件中,清晰的打印出了总时间,以及MVC各层消耗的时间,这为性能瓶颈分析提供了最直接的数据。例如,从下面的日志可以看出DB:1.2ms,View: 4.3ms,总时间:13ms

Started GET "/issues/attachments/86674" for 10.13.46.33 at 2012-04-28 20:58:50 +0800
Processing by AttachmentsController#view as JS
Rendered attachments/_screenshot.rhtml (0.3ms)
Rendered attachments/_attachment.rhtml (2.7ms)
Rendered attachments/view.js.erb (3.9ms)
Completed 200 OK in 13ms (Views: 4.3ms | ActiveRecord: 1.2ms)

request-log-analyzer

如果要从Rails日志中大海捞针式的找到性能瓶颈未免太痛苦了, request-log-analyzer可以帮助你解决这一问题。她能够分析rails日志,并能自动生成html报告,清楚的告诉你最常访问的URL,瓶颈最慢的URL,DB最慢的URL等等;这些信息对于你掌握系统的性能概况是很有帮助的。

newrelic

当掌握了慢URL后,接下来就是要分析rails在处理请求过程中具体的性能瓶颈,此时可以借助 newrelic工具来完成。她能够清晰的列举出Rails request过程中各SQL语句耗用的时间,以及MVC各层消耗的时间。但遗憾的是,免费版只能用development方式启动,而不能分析production的性能瓶颈。

当然也可以用ruby-prof来分析,但是她来者不拒,分析了所有ruby api的调用,通常分析一个request会得到几个百个api的数据,而从这里面要找出MVC哪一层出了问题是比较难的。

真正的问题:生产环境性能

在真实的场景中,Rails是以生产环境为用户提供服务,我们真正需要分析的是生产环境性能问题:哪个URL、什么时间、慢到什么程度,更进一步要分析问题出在哪个层面:DB,ruby计算,服务器等。要进行这些分析,需要拿到生产环境上的基础数据:慢URL(比如:responseTime超过5S),并且获得MVC各层消耗的具体时间。

抓取慢URL

在Rails3中要拿到这组基础数据并不难,利用Rails3提供的ActiveSupport::Notifications就可以获取详细的性能数据(类似Rails日志中的数据)。以下代码演示了Rails中如何捕获慢url,并记录到DB,供后续分析:

ActiveSupport::Notifications.subscribe "process_action.action_controller" \
do |name, start, finish, transaction_id, payload|
  total_duration = (finish - start) * 1000

  # record visited page rate by duration
  max_duration = 4700
  min_duration = 300
  if total_duration > (rand(max_duration) + min_duration)
    VisitedPage.create! do |page_request|
      page_request.path = payload[:path]
      page_request.total_duration = total_duration
      page_request.view_duration = payload[:view_runtime]
      page_request.db_duration = payload[:db_runtime]
      page_request.hostname = `hostname`.strip
    end
  end
end


常见分析方法

访问慢的URL

比如分析访问时间超过1S的:

select substring_index(path,'?',1) as url, avg(total_duration) as avg_duration, count(id) as count \
from visited_pages where total_duration > 1 and created_at > DATE_SUB(CURDATE(),INTERVAL 7 DAY) \
group by url order by avg_duration desc

分析结果:
url, avg_duration(ms), count
"uri1",162865,1
"uri2",162488,1
"uri3",161998,1

最耗费服务器资源的URL

访问慢的URL不一定就要优化,有两个方面可以来判定:用户是否能够感觉到,或者 对服务器负载是否高;
按负载来看 最需优化的URL:

select substring_index(path,'?',1) as url, SUM(total_duration) as sum_duration, \
avg(total_duration) as avg_duration, avg(db_duration) as avg_db, count(id) as count \
from visited_pages where created_at > DATE_SUB(CURDATE(),INTERVAL 7 DAY) \
group by url order by sum_duration desc

分析结果:
url, sum_duration(ms), count
"uri1",25873458,936
"uri2",21962420,710
"uri3",13119986,607

DB负载最高的URL

在一些请求当中,DB访问不合理会引起响应时间变长,db压力大;

select substring_index(path,'?',1) as url, SUM(db_duration) as sum_db_duration, count(id) as count \
from visited_pages where created_at > DATE_SUB(CURDATE(),INTERVAL 7 DAY) \
group by url order by sum_db_duration desc

分析结果:
url, sum_db_duration(ms), visited_count
"uri1",82088173,4666
"uri2",25319961,936
"uri3",5573929,607
"uri4",4121130,34

最繁忙的服务器

简单的说,可以按照机器承担的计算时间来评估 机器的负载是否过高;

select SUM(total_duration) as sum_duration, hostname from visited_pages \
where created_at > DATE_SUB(CURDATE(),INTERVAL 7 DAY) \
group by hostname order by sum_duration desc

分析结果:
sum_duration(ms), hostname
140590337,"host1"
21120945,"host1"
20193051,"host2"

最繁忙的时间段

通常,对于一个用户量大的系统,在一天24小时的访问量分布是有规律的。比如:通过对kelude服务器的CPU、Memory监控发现,工作日的09:00-10:00 负载是一天中最高的;
而下面按照24小时统计的计算负载分布 也反应了这一点:

select SUM(total_duration) as sum_duration, count(id) as cnt, hostname, hour(created_at) as h \
from visited_pages where created_at > DATE_SUB(CURDATE(),INTERVAL 7 DAY) \
group by hostname,h order by sum_duration desc;

分析结果:
sum_duration(ms), visited_count, hostname, hour
38837429,397,"host1",2
16109302,225,"host1",19
15204958,181,"host1",21
11442125,1463,"host2",0

基于上面的分析数据,相信你已经很清楚系统的性能瓶颈,然后再决定是否要优化DB,是否要添加ruby服务器,是否要负载均衡,是否要调整某些计算任务的时间等等。

相关 [rails3 性能分析 方法] 推荐:

Rails3中的性能分析方法

- - Taobao QA Team
(转帖请注明出处: http://qa.taobao.com/?p=15025). 性能分析是Web应用开发中非常重要的一个环节,相比访问缓慢的站点,访问快速的站点拥有更好的用户体验,帮助用户节省更多时间,带来更多的用户访问. 作为当前十分流行的Web框架, rubyonrails当然也提供很多方式进行性能分析.

locomotive - 用Rails3开发的开源CMS软件

- yuaz - ITeye资讯频道
用Rails做的CMS - locomotive ,功能超级棒. 支持多域名,可以对页面内部的不同区块直接编辑,所思即所得. 用的技术都很潮,Rails最新的版本3.0.7,存储用了MongoDB,内置多语言支持. 还是开源的:http://www.locomotivecms.com (要翻wall) ,国外已有软件公司用它做二次开发来卖CMS软件了.

rails3项目解析之4——异步和定时任务

- 董玉伟 - Ruby编程论坛最新讨论 - ITeye
上一篇:rails3项目解析之3——redis. 下一篇:rails3项目解析之5——rails on windows. 在当前的web应用中,尤其是互动概念越来越大行其道的今天,为了加快网站的反应速度,提高用户体验,有些操作不能等到所有的后台处理完成之后再展现给用户,因此需要引入异步任务机制. 典型的应用场景如用户注册完成之后的确认邮件发送,如果等邮件发送成功再给用户返回确认信息,这个时间间隔在用户体验上是难以接受的.

Android应用性能 分析

- - CSDN博客推荐文章
  其实主要是内存方面,内存管理是个永恒的话题. 1.从工具DDMS中,在Sysinfo的tab栏里面有一个Memory usage的选项,通过USB连接Android设备以后很容易抓到图. 在图中可以看到系统随时可以用的内存是Free和Buffers两项,因为我抓图的系统只有128M的内存,所以看上去这部分可用内存已经很少了.

lucene MoreLikeThis性能分析

- - 七磅-d0evi1
最近使用lucene的MoreLikeThis实现一个小型的推荐系统. 语料由短文本构成,本身也还算比较中小等规模:7000w左右(亿级别)的数据量,3G大小的文件. 对需要的Field建完索引后的索引文件大小在4G左右. 本文只是结合自己的实践列出一些注意事项,以做为参考. 一、MoreLikeThis实现原理.

Akka简单性能分析

- - 并发编程网 - ifeve.com
因为最近工作的关系,要把异步任务从应用服务器中拆分到专门的异步处理服务器中. 是采用MQ的方式将任务消息发出,在服务端进行处理,如下图所示:. 这种方案是采用MQ作为中间的媒介,在服务端采用线程池异步处理任务,处理完成之后将结果发送到MQ中,客户端采用侦听的方式得到结果继续进行处理. 这种方案的不足是,可能在某些需求的情况下,需要将结果存放到共享的HashMap或者Threadlocal中进行存放结果,客户端会一直阻塞,直到得到结果,从多线程的角度来说,还是用了共享变量,虽然共享变量可能是线程安全的,但是从并发模型的角度来讲,并不是一个最好的方式.

leveldb性能分析和表现

- Adam - Erlang非业余研究
原创文章,转载请注明: 转载自Erlang非业余研究. 本文链接地址: leveldb性能分析和表现. Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了. 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计. 那么数据库最怕的的随机IO他是如何解决的呢.

分布式事务性能分析

- wangdei - 风轻扬
这两年来,随着NoSQL系统、CAP理论和Eventual Consistency的大热,关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝. 双方各执一词,倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要,倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受. 弱一致性能否满足应用开发的需求这一点由应用特征决定,难以一概而论,但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的.

leveldb性能分析和表现

- mbcw - IT技术博客大学习
    Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了. 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计.     那么数据库最怕的的随机IO他是如何解决的呢.     先说随机写,它的写都是先记录到日志文件去的,在日志文件满之前只是简单的更新memtable,那么就把随机写转化成了顺序写.

【转载】HTML5性能分析面面观

- - HTML5研究小组
从性能角度来说,HTML5首先是缩减了HTML文档,使这件事情变得更简单. 第一,从用户可读性上说,原先一大堆东西,像初学者第一次看到这些东西是看不懂的,而HTML5的声明方式对用户来说显然更友好一些. 第二,文档编码的声明,用HTML5方式的话,就很简单. 我们说可以先用HTML5的方式就是把DOCTYPE先改了,因为目前很多页面都还是用传统的方式.