性能測试工具的主要作用是通过模拟生产环境中的真实业务操作，对被測试系统实行压力负载測试，监视被 測试系统在不同业务、不同压力性能下的性能表现。找出潜在的性能瓶颈进行分析、优化。
client与server相当于两个人，通过信息来进行交流。
因为初次见面不好意思直接交流。与是找来了中间传话人，client把信息告诉给传话人，由传话人来转达给server。那么server反馈的信息也由传话人转达给client。一般性能測试工具都须要录制或编写client行为脚本。
这样传达人就有了client的行为能力，从而假扮client来欺骗server，与之进行通信。有了client行为了传达人能够进行自我复制。从而变出N多个传达人对server进通信。—这个传达人的行为和能力也就是性能測试工具的基本特质。（突然觉得性能工具像第三者插足，并且是能够自我复制疯狂变态的第三者，哈哈！）
对于眼下流行的性能測试工具，他们的基本工作原理都是一致的。
在client通过多线程或多进程模拟虚拟用户訪问，对server端施加压力。然后在过程中监控和收集性能数据。
性能測试工具应该具备的特质：
1、工具本身占用系统资源少，可扩展性好，可用性强。
2、能模拟真实业务事务操作，在并发时能真正产生业务压力。
（这一点是核心）
3、对压力測试结果能非常好地进行性能分析，高速找出被測试系统的瓶颈。
4、測试脚本的反复性强。
前后端对照：
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 浏览器下，包括 IE6、IE7、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
设置
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
6、HTTP response codes: code 200 – 49 说明打开响应页面的类型，假设403的类型过多，那可能
要注意是否系统遇到了瓶颈。
特殊说明：
測试结果中基本的指标是 fetches/sec、msecs/connect 这个选项。即server每秒能够响应的查询次数，
用这个指标来衡量性能。似乎比 apache的ab准确率要高一些。也更有说服力一些。
Qpt-每秒响应用户数和response time，每连接响应用户时间。
測试的结果主要也是看这两个值。当然仅有这两个指标并不能完毕对性能的分析，我们还须要对server的
cpu、men进行分析。才干得出结论