前端和云端性能分析工具分析报告

　　性能測试工具的主要做用是经过模拟生产环境中的真实业务操做，对被測试系统实行压力负载測试，监视被 測试系统在不一样业务、不一样压力性能下的性能表现。找出潜在的性能瓶颈进行分析、优化。
　　client与server至关于两我的，经过信息来进行交流。

由于初次见面很差意思直接交流。与是找来了中间传话人，client把信息告诉给传话人，由传话人来转达给server。那么server反馈的信息也由传话人转达给client。通常性能測试工具都需要录制或编写client行为脚本。

这样传达人就有了client的行为能力，从而假扮client来欺骗server，与之进行通讯。有了client行为了传达人可以进行自我复制。从而变出N多个传达人对server进通讯。—这个传达人的行为和能力也就是性能測试工具的基本特质。（忽然以为性能工具像第三者插足，而且是可以自我复制疯狂变态的第三者，哈哈！）
　对于眼下流行的性能測试工具，他们的基本工做原理都是一致的。

在client经过多线程或多进程模拟虚拟用户訪问，对server端施加压力。而后在过程当中监控和收集性能数据。

性能測试工具应该具有的特质：
一、工具自己占用系统资源少，可扩展性好，可用性强。
二、能模拟真实业务事务操做，在并发时能真正产生业务压力。

（这一点是核心）
三、对压力測试结果能很是好地进行性能分析，高速找出被測试系统的瓶颈。
四、測试脚本的反复性强。

先后端对照：
Web应用的基础是超文本传输协议（HTTP）和超文本标记语言（HTML）。HTTP协议自己是一种面向非链接的协议，HTML语言则是一种用于制做超文本文档资料的简单标记语言。
　　对于一个页面而言，“请求”和“返回数据”均可能是屡次发生的。这个我在《在作性能測试以前需要知道什么》一文中举了一个简单的样例来解说。

由于HTTP对浏览器下载资源并发请求数量、Cache等方面都进行定义和限制，以及浏览器对于HTML的处理过程。全然可以说。用户因此感觉的响应时间中的至关大的一部分并不全然取决于应用的后台处理所需要的时间，而取决于web应用的前端。

在yahoo中，到少50个团队经过纯粹的前端性能相关的技巧，将终于用户的响应时间下降了25%以上。
　　HTTP是一个属于应用层的面向对象的协议。用于传送WWW方式的数据，採用请求\响应模型，client向server发送一个请求，请求头包括请求的方法、URI、协议版本号。以及包括请求修饰符、客户信息和内容的类似于HTML的消息结构。

server以一个状态行做为响应。响应的内容包括消息协议的版本号。成功或者错误编码加上包括server信息。实体元信息以及可能的实体内容。
　　 HTML是一种用于制做超文本文档资料的简单标记语言，用HTML编写的超文本文档可以独立于各类操做系统平台。从诞生開始，HTML语言就一直被用于描写叙述web页面格式设计。使用HTML语言描写叙述的文件需要经过WWW浏览器显示效果。

如下用两种方式来对照较两种測试响应时间的区别
　　Apache benchmark 简称ab ，是很是有名又小巧的压力測试工具。

　　下载安装apache web server 安装或解压以后，在bin\文件夹下有个ab运行文件。
　　打开运行–cmd 打开命令提示符。定位到bin\文件夹下。
基本用法：
ab -c [并发用户数] -n [发送请求数] [被測试页面的URL]
设置一个用户一个请求，对百度首页加压：
http://www.baidu.com/

从上表中咱们可以看到请求的总字节数为8024字节；响应时间为0.173 秒，也就是如下显示的173.010毫秒。

---

Firebug很是有名的debug工具，firefox浏览器最得意的集成工具。
在firefox浏览菜单条“工具”—加入组件—搜索firebug下载安装从新启动浏览器。
相同对百度首页的訪问：
http://www.baidu.com/

从上面图中看到请求的大小为10KB；响应时间1.4秒。清楚的发现这数据可以远远大于ab工具所获得的数据。细致观察发现，firebug给出的数据，訪问 http://www.baidu.com/ 网址时，client（浏览器）和应用之间的数据交互并不是1次，而是5次。
　　咱们再分析当中的一个请求，firefox给出的的图形中，有红色和蓝色两种颜色的线条。蓝色表示到此刻发生了DOMContentLoaded事件。红色线条表示onload事件被触发。DOMContentLoaded事件W3C推荐的标准事件。它发生在页面的DOM树建成时，而onload则发生在页面所有的资源（图片文件、CSS文件、js文件等）都被下载完毕后。

　　从上图的右下角，咱们会获得两个响应时间，1.41秒是onload事件被触发的时间。前面的1.4秒则是页面的所有请求都返回所需要的总时间。那么哪一个时间才是用户感觉到的响应时间呢？准确的说，两个都不是。

用户的感觉是个不肯定的状态。取决于页面自己的类型以及呈现手段。假设某页面仅为用户提供阅读信息，一旦页面上開始出现可供阅读的内容，用户就開始阅读了。

那么，用户以为响应时间就是发出请求到页面上出现可阅读信息。假设页面存在大量的交互内容。需要用户填写或在页面上进行拖拽等操做，在这样的状况下。仅仅有当页面的所有元素都被下正确的呈现出来。所有的js文件都已经运行完毕后，用户才会感觉到这个页面已经就绪。
　　Web前端性能的研究并不是为了准确地获得一个响应时间数据，实际上，依据friebug图表的结果，web性能一部分取决于webserver和应用server（创建链接，下载链接），别一部分取决于浏览器的实现机制、web页面上的js的运行等。取决于webserver和应用server的响应时间与server的负载、压力等相关；而取决于浏览器实现机制与js文件运行所需要的时间则差点儿与server端的负载和压力无关。

那么web端的响应时间也是总响应时间的一部分，那么有必要web端的性能进行了解。
　　那么前端性能这么见效。为何还要去作后端性能測试呢？由于他们关注点不一样，前端性能关注单个用户的感觉。

后端性能关注是不少其它用户訪问系统时，server能更稳定、更快的处理用户发来的请求。一个强大的后台是前台的基础。

前端:

性能測试一直是 Web 应用中很是受关注的部分。眼下大多数人对性能的关注还主要集中在服务端，大部分人在说到“性能測试”的时候。都会把重点放到服务端的性能測试和调优，也就是经过各类方法找到服务端的性能瓶颈并尝试对其进行调优。但实际上。对于 web 应用来讲，除了考虑服务端在足够短的时间内返回页面数据以外，还可以从页面 前端 的角度来考虑性能測试和性能调优。

在线站点类：
WebPageTest
说明：
在线的站点性能评測站点，地址http://www.webpagetest.org/
补充：
事实上这站点也是个开源项目，因此支持本身搭建一个内部的測试站点

独立程序类：
DynaTrace Ajax Edition
说明：
基于IE，firefox的插件。对于FF需要版本号支持，需要独立安装文件（50多M）。其可支持到函数级的度量分析，此外其它工具能支持的功能这个工具都支持的。

这个工具可以跟踪JavaScript从运行開始。通过本地的XMLHttpRequest、发送网络请求，再到请求返回的全过程。

什么是 dynaTrace Ajax
随着 jQuery、Dojo、YUI 等框架的兴起让构建 Web2.0 应用更加easy。但随之带来的定位等应用问题也愈来愈难，尤为是与性能相关的。

dynaTrace Ajax Edition 是一个强大的底层追踪、前端性能分析工具，该工具不只可以记录浏览器的请求在网络中的传输时间、前端页面的渲染时间、DOM 方法运行时间以及 JavaScript 代码的解析和运行时间，还可以跟踪 JavaScript 从运行開始。通过本地的 XMLHttpRequest、发送网络请求、再到请求返回的全过程。
dynaTrace Ajax 眼下有两个版本号，免费版和商业版，它们之间的区别可查看 版本号比較，本文主要是针对免费版本号的介绍。

在 3.0 以前的版本号仅仅支持运行在 IE 浏览器下，包括 IE六、IE七、IE8， 在 3.0 Beta 版以后可同一时候支持在 IE 和 Firefox 浏览器上的性能跟踪。

应用案例分析
如下记录的结果是以咱们眼下正开发的一个实际项目（IBM Docs）中的一个案例 - 在 Web 中打开一个 PPT 文档。依据 dynaTrace 收集的信息来分析存在的性能问题。
Performance Report( 性能报告视图 )
从 Cockpit 面板中打开 Performance Report 视图。如图所看到的：
图. 性能报告

性能报告视图中记录了所有訪问的网页的具体信息，从这个视图当中咱们可以获得如下信息：
加载页面所消耗的时间 ：OnLoad Time[ms] 显示从页面開始加载到浏览器派发 onload 事件所经历的时间。Total Load Time[ms] 显示页面所有 load 完总共消耗的时间
JavaScript 运行时间 ：On Client[ms] 经过 JS API 或库运行的所有 JavaScript 函数所消耗的总时间
网络请求花了多长时间： 从 Remark 中可看到总共同拥有多少请求数。当中有多少 XHR 请求等信息
server端所消耗时间： On Server[ms] 指client发出的所有请求在server过了多长时间開始响应所消耗的总时间
从右下方的各个面板中可以获得总体的性能分析报告（更具体的信息可查看 Cockpit 面板中的对应节点），好比：
NetWork 中可看出有多少资源是从浏览器缓存中读取的，有多少的 HTTP 转发请求消耗了没必要要的网络传输时间。合并同一个 domain 中的 CSS、JS 的请求可节省多长网络传输时间。

TimeLine 中显示了页面的生命周期：该图反映了页面进程中网络资源下载。JavaScript 运行，页面发生渲染，CPU 使用状况。以及发生了哪些事件。好比：Load 事件、XMLHttpRequest 等信息。

在个人样例中。如下内容引发了个人注意：
网络耗时较长，请求数目太多：总共同拥有 896 网络请求。当中有 300+ 个 request 是对图片的请求。300+ 个是从 cache 中对相同图片的读取。
JavaScript 运行时间总耗时 22 秒： 从右下方的 JavaScript/Ajax(A) 报告中可看出有一个 OnLoad 的事件就消耗了总共 13 秒 的时间，双击可从右边窗体看出它的先后调用栈信息。
Server 端处理总共花了 20 秒 的时间 : 这说明 Server 端也可能存在性能问题，可推荐你们使用 Performance Inspector工具去分析 Server 端的性能问题，这里再也不详述。

Remark 栏还显示了页面总共发出了 23 个 XMLHttpRequest 请求: 这可以从时间轴的 event 行中找出发生的时间点。

下一节将会针对这些问题进行更具体的讨论。
Timeline( 时间轴视图） - 页面生命周期
时间轴视图可以经过双击 Cockpit 面板中的 TimeLine 节点打开或者在 Performance Report 中经过在某个 URL 上点击右键。选择“DrillDown-TimeLine ”打开。依据 性能报告视图 打开耗时比較长的 URL 的 TimeLine, 经过工具栏或右键菜单。可以打开不少其它选项，比方内容类型和 JavaScript 触发器的颜色值，或者显示不少其它事件，比方鼠标移动、点击和键盘事件。打开本案例的时间轴视图，如图 所看到的：
图. 时间轴

在此视图下。咱们可观測到：
CPU 占用率可显示 JavaScript 的运行致使浏览器占用 CPU 的时间
JavaScript 运行所占用的时间：从上图中观察到右边蓝色块的那一段耗时比較长。鼠标悬停在这段上可以看到是由于 load event on 触发的。耗时将近 13 秒 的时间
浏览器 Rendering，悬停上去可发现大部分是由于在计算 layout 所需要的时间，通常在 IE 上面运行相对会比較明显
网络请求并行下载耗时，一方面来自请求的数目太多，当中一个比較明显的就是有一个 XMLHttpRequest 花在 Server 的处理耗时将近 7 秒的时间
Event 轴显示了鼠标点击事件，XMLHttpRequest 事件和 OnLoad 事件
放大右边网络请求时间比較长的部分（在个人样例中，从 16s 到 29s 时间片 ), 经过在開始处点击鼠标左键拖拽到结束位置松开鼠标拖拽。视图将放大到如下截图中显示的时间片上。例如如下图 所看到的 :
图. 放大时间轴

经过放大的时间片右键选择“Drill Down to Timeframe e”进入 PurePath 视图。显示当前所放大的时间片上所有的活动。

dynaTrace Ajax 是前端的软件开发project师和性能分析师的很是实用且重要的工具。经过该工具的不断更新，功能的不断强大，所支持的浏览器的不断添加以及与持续集成工具相结合，这样就可以更easy、更早、更频繁地发现应用程序在不一样浏览器上的性能问题。

后端：
无论什么评測工具，基本的技术都是利用线程技术模仿和虚拟用户，在这里基本的难点在于測试脚本的编写，每种工具使用的脚本都不同。但是大多数工具都提供录制功能就算是不会编码的測试人员相同可以測试。

众所周知，server是整个网络系统和计算平台的核心。不少重要的数据都保存在server上。很是多网络服务都在server上运行，所以server性能的好坏决定了整个应用系统的性能。
现在市面上不一样品牌、不一样种类的server有很是多种。用户在选购时，如何从纷繁的型号中选择出所需要的，适合于本身应用的server产品，仅仅从配置上判别是不够的。最好可以经过实际測试来筛选。而各类的评測软件有很是多种，你应该选择哪一个软件測试？如下就介绍一些较典型的測试工具：
（一）server整机系统性能測试工具
一台server系统的性能可以依照处理器、内存、存储、网络几部分来划分，而针对不一样的应用，可能会对某些部分的性能要求高一些。

（二）针对应用的測试工具

　　随着web应用的增多，server应用解决方式中以Web为核心的应用也愈来愈多，很是多公司各类应用的架构都以web应用为主。通常的web測试和以往的应用程序的測试的側重点不全然相同，在基本功能已经经过測试后。就要进行重要的系统性能測试了。系统的性能是一个很是大的概念。覆盖面很是普遍。对一个软件系统而言包括运行效率、资源占用率、稳定性、安全性、兼容性、可靠性等等，如下重点从负载压力方面来介绍server系统性能的測试。

系统的负载和压力需要採用负载測试工具进行。虚拟必定数量的用户来測试系统的表现。看是否知足预期的设计指标要求。负载測试的目标是測试当负载逐渐添加时，系统组成部分的对应输出项，好比经过量、响应时间、CPU负载、内存使用等如何决定系统的性能。好比稳定性和响应等。

负载測试通常使用工具完毕。有Loadrunner，Webload，QALoad等，基本的内容都是编写出測试脚本。脚本中通常包括用户常用的功能，而后运行，得出报告。使用压力測试工具对webserver进行压力測试。

測试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等。由于有些存在内存泄漏问题的程序，在运行一两次时可能不会出现故障，但是假设运行了成千上万次，内存泄漏得愈来愈多。就会致使系统崩滑。

ab是Apache超文本传输协议(HTTP)的性能測试工具。

其设计意图是描绘当前所安装的Apache的运行性能， 主要是显示你安装的Apache每秒可以处理多少个请求。

ab [ -A auth-username:password ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -v verbosity] [ -V ] [ -w ] [ -x

-attributes ] [ -X proxy[:port] ] [ -y -attributes ] [ -z

-attributes ] [http://]hostname[:port]/path

选项

-A auth-username:password
对server提供BASIC认证信任。 username与password由一个:隔开。并以base64编码形式发送。

无论server是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-c concurrency
一次产生的请求个数。默认是一次一个。
-C cookie-name=value
对请求附加一个Cookie:行。 其典型形式是name=value的一个參数对。 此參数可以反复。
-d
不显示”percentage served within XX [ms] table”的消息(为曾经的版本号提供支持)。

-e csv-file
产生一个以逗号分隔的(CSV)文件， 当中包括了处理每个对应百分比的请求所需要(从1%到100%)的对应百分比的(以微妙为单位)时间。 由于这样的格式已经“二进制化”。因此比’gnuplot’格式更实用。

-g gnuplot-file
把所有測试结果写入一个’gnuplot’或者TSV (以Tab分隔的)文件。 此文件可以方便地导入到Gnuplot, IDL, Mathematica, Igor甚至Excel中。 当中的第一行为标题。

-h
显示用法。
-H custom-header
对请求附加额外的头信息。

此參数的典型形式是一个有效的头信息行，当中包括了以冒号分隔的字段和值的对 (如, “Accept-Encoding: zip/zop;8bit”).
-i
运行HEAD请求，而不是GET。

-k
启用HTTP KeepAlive功能。即, 在一个HTTP会话中运行多个请求。 默认时，不启用KeepAlive功能.
-n requests
在測试会话中所运行的请求个数。 默认时。仅运行一个请求，但一般其结果不具备表明意义。
-p POST-file
包括了需要POST的数据的文件.
-P proxy-auth-username:password
对一个中转代理提供BASIC认证信任。 username与password由一个:隔开，并以base64编码形式发送。 无论server是否需要(即, 是否发送了401认证需求代码)。此字符串都会被发送。

-q
假设处理的请求数大于150， ab每处理大约10%或者100个请求时，会在stderr输出一个进度计数。

此-q标记可以抑制这些信息。
-s
用于编译中(ab -h会显示相关信息)使用了SSL的受保护的https， 而不是http协议的时候。

此功能是实验性的，也是很是简陋的。最好不要用。
-S
不显示中值和标准背离值， 而且在均值和中值为标准背离值的1到2倍时，也不显示警告或出错信息。 默认时。会显示 最小值/均值/最大值等数值。

(为曾经的版本号提供支持).
-t timelimit
測试所进行的最大秒数。

其内部隐含值是-n 50000。 它可以使对server的測试限制在一个固定的总时间之内。默认时，没有时间限制。
-T content-type
POST数据所使用的Content-type头信息。

-v verbosity
设置显示信息的具体程度 - 4或更大值会显示头信息。 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其它信息。
-V
显示版本号号并退出。
-w
以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。
-x

-attributes
设置 属性的字符串。 此属性被填入

tar zxvf http_load-12mar2006.tar.gz

cd http_load-12mar2006

make && make install

命令格式：http_load -p 并发訪问进程数 -s 訪问时间 需要訪问的URL文件
參数事实上可以自由组合，參数之间的选择并无什么限制。

比方你写成http_load -parallel 5 -seconds
300 urls.txt也是可以的。咱们把參数给你们简单说明一下。
-parallel 简写-p ：含义是并发的用户进程数。
-fetches 简写-f ：含义是总计的訪问次数
-rate 简写-p ：含义是每秒的訪问频率
-seconds简写-s ：含义是总计的訪问时间
准备URL文件：urllist.txt，文件格式是每行一个URL，URL最好超过50－100个測试效果比較好.文件格式
例如如下：
http://www.vpser.net/uncategorized/choose-vps.html
http://www.vpser.net/vps-cp/hypervm-tutorial.html
http://www.vpser.net/coupons/diavps-april-coupons.html
http://www.vpser.net/security/vps-backup-web-mysql.html
好比：
http_load -p 30 -s 60 urllist.txt
參数了解了，咱们来看运行一条命令来看看它的返回结果
命令：% ./http_load -rate 5 -seconds 10 urls说明运行了一个持续时间10秒的測试，每秒的频率为5。

49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274
fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first
-response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 – 49
结果分析：
1．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
说明在上面的測试中运行了49个请求，最大的并发进程数是2。总计传输的数据是289884bytes。运行的时间是10.0148秒
2．5916 mean bytes/connection说明每一链接平均传输的数据量289884/49=5916
3．4.89274 fetches/sec, 28945.5 bytes/sec
说明每秒的响应请求为4.89274，每秒传递的数据为28945.5 bytes/sec
4．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min说明每链接的平均响应时间是28.8932 msecs
。最大的响应时间44.243 msecs，最小的响应时间24.488 msecs
5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
六、HTTP response codes: code 200 – 49 说明打开响应页面的类型，假设403的类型过多，那可能
要注意是否系统遇到了瓶颈。

特殊说明： 測试结果中基本的指标是 fetches/sec、msecs/connect 这个选项。即server每秒可以响应的查询次数， 用这个指标来衡量性能。彷佛比 apache的ab准确率要高一些。也更有说服力一些。 Qpt-每秒响应用户数和response time，每链接响应用户时间。 測试的结果主要也是看这两个值。固然仅有这两个指标并不能完毕对性能的分析，咱们还需要对server的 cpu、men进行分析。才干得出结论