性能测试工具的主要作用是通过模拟生产环境中的真实业务操作，对被测试系统实行压力负载测试，监视被 测试系统在不同业务、不同压力性能下的性能表现，找出潜在的性能瓶颈进行分析、优化。
　　客户端与服务器相当于两个人，通过信息来进行交流。由于初次见面不好意思直接交流，与是找来了中间传话人，客户端把信息告诉给传话人，由传话人来转达给服务器。那么服务器反馈的信息也由传话人转达给客户端。一般性能测试工具都需要录制或编写客户端行为脚本。
这样传达人就有了客户端的行为能力，从而假扮客户端来欺骗服务器，与之进行通信。有了客户端行为了传达人可以进行自我复制。从而变出N多个传达人对服务器进通信。—这个传达人的行为和能力也就是性能测试工具的基本特质。（突然觉得性能工具像第三者插足，而且是可以自我复制疯狂变态的第三者，哈哈！）
　对于目前流行的性能测试工具，他们的基本工作原理都是一致的。在客户端通过多线程或多进程模拟虚拟用户访问，对服务器端施加压力，然后在过程中监控和收集性能数据。

性能测试工具应该具备的特质：
1、工具本身占用系统资源少，可扩展性好，可用性强。
2、能模拟真实业务事务操作，在并发时能真正产生业务压力。（这一点是核心）
3、对压力测试结果能很好地进行性能分析，快速找出被测试系统的瓶颈。
4、测试脚本的重复性强。

前后端对比：
Web应用的基础是超文本传输协议（HTTP）和超文本标记语言（HTML），HTTP协议本身是一种面向非连接的协议，HTML语言则是一种用于制作超文本文档资料的简单标记语言。
　　对于一个页面而言，“请求”和“返回数据”都可能是多次发生的。这个我在《在做性能测试之前需要知道什么》一文中举了一个简单的例子来讲解。由于HTTP对浏览器下载资源并发请求数量、Cache等方面都进行定义和限制，以及浏览器对于HTML的处理过程。完全可以说，用户所以感受的响应时间中的相当大的一部分并不完全取决于应用的后台处理所需要的时间，而取决于web应用的前端。在yahoo中，到少50个团队通过纯粹的前端性能相关的技巧，将最终用户的响应时间减少了25%以上。
　　HTTP是一个属于应用层的面向对象的协议，用于传送WWW方式的数据，采用请求\响应模型，客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本，以及包含请求修饰符、客户信息和内容的类似于HTML的消息结构。服务器以一个状态行作为响应，响应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息，实体元信息以及可能的实体内容。
　　 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/ 网址时，客户端（浏览器）和应用之间的数据交互并非1次，而是5次。
　　我们再分析其中的一个请求，firefox给出的的图形中，有红色和蓝色两种颜色的线条。蓝色表示到此刻发生了DOMContentLoaded事件。红色线条表示onload事件被触发。DOMContentLoaded事件W3C推荐的标准事件，它发生在页面的DOM树建成时，而onload则发生在页面所有的资源（图片文件、CSS文件、js文件等）都被下载完成后。
　　从上图的右下角，我们会得到两个响应时间，1.41秒是onload事件被触发的时间，前面的1.4秒则是页面的所有请求都返回所需要的总时间。那么哪个时间才是用户感受到的响应时间呢？准确的说，两个都不是。用户的感受是个不确定的状态，取决于页面本身的类型以及呈现手段。如果某页面仅为用户提供阅读信息，一旦页面上开始出现可供阅读的内容，用户就开始阅读了。那么，用户认为响应时间就是发出请求到页面上出现可阅读信息。如果页面存在大量的交互内容，需要用户填写或在页面上进行拖拽等操作，在这种情况下，只有当页面的所有元素都被下正确的呈现出来，所有的js文件都已经执行完成后，用户才会感受到这个页面已经就绪。
　　Web前端性能的研究并不是为了准确地得到一个响应时间数据，实际上，根据friebug图表的结果，web性能一部分取决于web服务器和应用服务器（建立连接，下载连接），别一部分取决于浏览器的实现机制、web页面上的js的执行等。取决于web服务器和应用服务器的响应时间与服务器的负载、压力等相关；而取决于浏览器实现机制与js文件执行所需要的时间则几乎与服务器端的负载和压力无关。那么web端的响应时间也是总响应时间的一部分，那么有必要web端的性能进行了解。
　　那么前端性能这么见效，为什么还要去做后端性能测试呢？因为他们关注点不同，前端性能关注单个用户的感受。后端性能关注是更多用户访问系统时，服务器能更稳定、更快的处理用户发来的请求。一个强大的后台是前台的基础。

前端:

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

在线网站类：
WebPageTest
说明：
在线的站点性能评测网站，地址http://www.webpagetest.org/
补充：
其实这网站也是个开源项目，所以支持自己搭建一个内部的测试站点

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

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

什么是 dynaTrace Ajax
随着 jQuery、Dojo、YUI 等框架的兴起让构建 Web2.0 应用更加容易，但随之带来的定位等应用问题也越来越难，尤其是与性能相关的。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 请求等信息
服务器端所消耗时间： On Server[ms] 指客户端发出的所有请求在服务器过了多长时间开始响应所消耗的总时间
从右下方的各个面板中可以得到总体的性能分析报告（更详细的信息可查看 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 是前端的软件开发工程师和性能分析师的非常有用且重要的工具。通过该工具的不断更新，功能的不断强大，所支持的浏览器的不断增加以及与持续集成工具相结合，这样就可以更容易、更早、更频繁地发现应用程序在不同浏览器上的性能问题。

后端：
无论什么评测工具，基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在于测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
众所周知，服务器是整个网络系统和计算平台的核心，许多重要的数据都保存在服务器上，很多网络服务都在服务器上运行，因此服务器性能的好坏决定了整个应用系统的性能。
现在市面上不同品牌、不同种类的服务器有很多种，用户在选购时，怎样从纷繁的型号中选择出所需要的，适合于自己应用的服务器产品，仅仅从配置上判别是不够的，最好能够通过实际测试来筛选。而各种的评测软件有很多种，你应该选择哪个软件测试？下面就介绍一些较典型的测试工具：
（一）服务器整机系统性能测试工具
一台服务器系统的性能可以按照处理器、内存、存储、网络几部分来划分，而针对不同的应用，可能会对某些部分的性能要求高一些。
（二）针对应用的测试工具

　　随着web应用的增多，服务器应用解决方案中以Web为核心的应用也越来越多，很多公司各种应用的架构都以web应用为主。一般的web测试和以往的应用程序的测试的侧重点不完全相同，在基本功能已经通过测试后，就要进行重要的系统性能测试了。系统的性能是一个很大的概念，覆盖面非常广泛，对一个软件系统而言包括执行效率、资源占用率、稳定性、安全性、兼容性、可靠性等等，以下重点从负载压力方面来介绍服务器系统性能的测试。系统的负载和压力需要采用负载测试工具进行，虚拟一定数量的用户来测试系统的表现，看是否满足预期的设计指标要求。负载测试的目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等如何决定系统的性能，例如稳定性和响应等。负载测试一般使用工具完成，有Loadrunner，Webload，QALoad等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。使用压力测试工具对web服务器进行压力测试。测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。

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

选项

-A auth-username:password
对服务器提供BASIC认证信任。 用户名和密码由一个:隔开，并以base64编码形式发送。 无论服务器是否需要(即, 是否发送了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认证信任。 用户名和密码由一个:隔开，并以base64编码形式发送。 无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-q
如果处理的请求数大于150， ab每处理大约10%或者100个请求时，会在stderr输出一个进度计数。 此-q标记可以抑制这些信息。
-s
用于编译中(ab -h会显示相关信息)使用了SSL的受保护的https， 而不是http协议的时候。此功能是实验性的，也是很简陋的。最好不要用。
-S
不显示中值和标准背离值， 而且在均值和中值为标准背离值的1到2倍时，也不显示警告或出错信息。 默认时，会显示 最小值/均值/最大值等数值。(为以前的版本提供支持).
-t timelimit
测试所进行的最大秒数。其内部隐含值是-n 50000。 它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
-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 这个选项，即服务器每秒能够响应的查询次数，
用这个指标来衡量性能。似乎比 apache的ab准确率要高一些，也更有说服力一些。
Qpt-每秒响应用户数和response time，每连接响应用户时间。
测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的
cpu、men进行分析，才能得出结论