经过两周左右时间的工作,目前搜索应用中文站searchweb前端页面性能自动化体系已经建立完成。在构建过程中我们使用了selenium驱动浏览器运行,并将结果写入dynaTrace进行分析的方式。目前搜索应用中文站已经完成了searchweb前端所有页面的性能自动化脚本覆盖,现在的自动化体系共包括74个java脚本,覆盖的浏览器包括IE和Firefox(两种浏览器的脚本有所不同,每种浏览器各37个),IE浏览器所有脚本的总执行时间在25min左右,Gecko内核的Firefox总时间在20min左右,具体覆盖如下: 1.黄白展位部分:脚本个数3*2 2. p4p热门推荐:脚本个数为6*2 3.行业化页面:脚本个数3*2 4.SN区域:脚本个数14*2 5.Open Widget:脚本个数7*2 6.combo2.0:脚本个数1*2 7.零结果页面:脚本个数3*2
运行环境&性能结果分析:
在运行工程的Run_All.java文件后(这个是总调度文件),所有运行的结果会自动写入dynatrace,命名方式采用了跟脚本相同的名字,这样方便查找结果,结果树如下:
该统计反映了页面交互的时序,按访问的域划分,可以清晰的看到在某个时间段系统cpu的消耗、以及请求发送的时序
可以查看JS的function执行时间消耗,方便根据请求的响应流程来debug代码
我们最关注的部分,直接记录在页面加载过程中的时间消耗百分比排名,主要是一些JS的function和浏览器render等,从截图中也可以很清晰的看出来,这些都是资源消耗的大户。
上图是IE浏览器下加载主搜纯K查询页面资源消耗的热点分析,从中我们可以很清晰的看出,IE浏览器确实比较慢…render的时间消耗排名都排在了最前面的几个位置;再就是一些YUI库函数的执行消耗的时间也比较长,后续可以看看这些库函数是否有可以优化的空间
在这个热点分析中有一个现象有点奇怪,就是在Firefox下我们看不到render的单独时间,如下:
我遍历了所有Contributor都没有发现这个render的时间,不知道是不是与系统对不同浏览器的支持有所不同导致,咨询了一下架构的陈寄文同学,在Firefox下这个时间可能已经被包含在某个function的执行或者JS的parsing时间里了,具体的后续还要研究下(由于dynatrace在3.0以后才支持FireFox,而3.0目前还是beta版,对FireFox的支持还不是太好)
为何选择Selenium&dynaTrace? Selenium是轻便的自动化测试框架,其核心的browser bot是用JS编写的,对各种浏览器都具有极佳的支持性;而dynaTrace是目前最好的IE浏览器下的性能分析工具,可以方便的分析 JavaScript的执行、Http Requests、DOM操作、框架、布局和渲染等。
之前的dynaTrace是不支持Firefox的,但是从3.0版本已经开始支持对Firefox的profile。因此我们这次分析时采用了它的3.0版本,虽然还是beta版本,不过对Firefox性能的分析还是比firebug等工具要强悍,可惜的是目前的版本对最新的FireFox 4.0支持性不好,在运行的过程中浏览器会出现崩溃,因此现阶段我们还是采用了FireFox的3.6版本
另外,如果浏览器当前页面关闭后iexplore.exe或者firefox.exe仍然存在的话,运行下一个脚本写入的时候会出现错误,因此我在每个脚本最后都调用了runtime来杀死当前进程,避免冲突的发生
|