》》》推荐阅读《《《

1、性能测试学习笔记-场景设计

2、性能测试的重要意义

3、性能分析流程及方法

4、应用系统性能调优之性能分析

性能测试实战-场景设计

一、性能测试流程

计划测试->创建脚本->创建场景->运行场景->分析性能数据->生成x性能测试报告，如下图所示：

1.1 计划测试

在任何类型的测试中，编写测试计划都是必要的步骤。有条不紊、计划周密的计划，可以确保在执行中能够有章可循。在计划测试阶段需要输出性能测试计划，而计划阶段需要经历如下几个环节，如下图所示： 

 1.1.1 分析系统阶段

要进行性能测试，了解被测对象是需要做的第一步。首先需要确认系统的架构和所使用的协议，对工具的可行性进行分析，然后对整个业务进行熟悉，确认相关的数据和业务操作可以被工具录制回放。

✔ 通过分析系统阶段需要知道该系统能不能进行性能测试。

1. 确定协议

如何确定系统所使用的协议，这是大家经常讨论的问题，其实询问一下需求分析人员或开发人员就知道，绝大多数时候系统都使用标准的开发架构，而所使用的协议也是系统事先封装好的，不过万一开发人员也不知道系统到底使用了哪些协议呢？这时不能随意悬着录制协议，否则会由于漏录软件交互协议导致回放失败，或录制了大量无用交互协议导致脚本无法维护，这时就需要引入网络数据包拦截分析，来确认系统协议。

网络数据包拦截软件其实有很多，比如常见的Wireshark、Omnipeek等。通过这类工具，可以拦截整个被测系统所使用的协议类型，甚至明确数据包的封装格式。它们和HttpWach略有不同，HTTPWatch是一个基于浏览器的插件，可以帮助我们拦截HTTP的数据包；而这里使用的网络拦截工具是基于网卡的底层扫描的。

这里以Omnipeek为例具体说明一下。Omnipeek是由Wildpackets公司研发的网络扫描维护工具，其提供了高效的故障诊断和定位能力，这一特性能够明显缩减日常花费大量寻障和排障的时间，使我们有精力去完善日常其他的工作以及学习更多的业务知识。在很长一段时间内，Sniffer都是网络扫描和数据包拦截方面的指导性软件，作为后起之秀的Omnipeek，在最近几年中其锋芒已经压过Sniffer成为各大杂志推荐的最佳产品。

Omnipeek提供以下几种功能，可帮助测试人员快速对网络问题进行故障诊断/定位。

主机排名。发现网络中通信量最大的主机，对比故障现象与影响范围，如下图所示：

协议排名。可以对监控的所有协议进行排名，找到使用最多的协议，如下图所示：

具体哪些主机在使用某种通信协议，如下图所示：

通过PeerMap网络分布图了解主机会话的实时情况，如下图所示： 

深入解码分析。发现异常后，可以进行深入的解码分析，如下图所示： 

通过以上步骤可以很容易的发现流量异常的主机、主机不正常的协议通信以及网络中实际传输的数据内容。从某些角度来说，使用Omnipeek来做协议分析，真是杀鸡用牛刀。读者可以在各大网络下载到免费版本的Omnipeek安装包。下面我们使用Omnipeek来尝试捕捉和分析系统，了解其使用的网络协议。

打开Omnipeek，在主界面的左上侧单机New Capture按钮，如下图所示：

新建一个数据捕捉，弹出Capture Options协议捕捉设置窗口，如下图所示：

在这里需要设置以下内容。

General中的捕捉名称。

Adapter需要捕捉的设备。

Filters对于协议包的过滤规则。

在多网卡的情况下，这里选择的设备不能有错，否则会导致没有数据包被捕捉的情况。确认后进入监控页面，如下图所示：

单击Start Capture按钮就可以开始进行协议捕获了。

如果现在想知道自己的有线网卡在做些什么，那么只要确保前面设置的捕获设备是本地网卡即可，不需要设置任何Filters过滤规则，单击Start Capture按钮开始捕获，稍等片刻，可以看到有大量的数据包被捕获下来，如下图所示：

在列表中可以看到通过网络数据包捕获得到了每个请求的发送源、接收请求的地址、数据包的大小、传送时间及协议类型。

通过这种方式可以轻松地确认需要进行性能测试的系统所使用的协议类型。另一方面还能对每个请求进行更加深入的分析，双击打开请求，即可得到该请求的详细分析，包括发送的数据包格式、所使用的协议及该协议下的数据内容，如下图所示：

一般从性能测试工具的协议选择角度来说，应尽可能使用高级的协议，作为底层的Windows Sockets 协议只有在万不得已的情况下才使用。通过工具分析扫描以后可以确定系统所使用的协议类型、协议格式和封包规则，而Omnipeek几乎能够识别所有的协议标准，下图所示：

扫描后可以根据扫描的结果去检查VuGen是否支持这种协议，如果遇到VuGen不支持的协议，那么使用LoadRunner来进行性能测试可能就不是最佳选择，虽然可以通过Windows Sockets来模拟这个过程，但是使用过程相对烦琐。

对于这次需要测试的Phpwind和Discuz论坛来说，从其官方网站可以了解这是基于PHP技术的B/S架构论坛系统，在客户端上通过HTTP完成对整个论坛的访问，所以确认该系统可以使用LoadRunner的HTTP协议完成操作的录制，该工具是适合进行该系统的性能测试的。

2. 熟悉业务流程

每一个系统都有自己的业务流程，通过查看相关文档，可以了解系统的执行步骤和业务流程，从而了解用户如何使用整个系统。我们需要先将各种业务操作的流程进行整理，并且通过VuGen进行录制回放，检查该系统是否能够被性能测试工具模拟用户行为。

对于一个要测试的论坛来说，常见的操作包括发帖、查看帖子、用户间收发短消息等操作。这里简单分析一下用户进行常见操作所需要的一些业务流程。

1）浏览帖子

一个论坛所能提供给用户主要的功能就是帖子的浏览功能，绝大多数情况下论坛都会被设置为无需登录即可浏览大部分板块的帖子。用户在访问到论坛首页后会点击自己感兴趣的板块，并且进行前后翻页，查找自己关心的话题，然后进入该话题，进行浏览操作。

2）查询帖子

使用搜索引擎是大家最常做的事情，而论坛也提供了强大的查询功能。当登录系统后，就可以使用查询功能在论坛中查找各种话题，查询后列出符合查询条件的相关记录，查询速度一般受到论坛数据量的影响较大。

3）回帖/发帖

相对于浏览来说，回帖或发帖的操作并不会如此频繁，用户发帖或回帖需要先登录论坛，进入在线用户状态后，即可在不同的模块中进行发帖或对某些帖子进行回帖操作。

4）注册新用户

当用户想要进行回帖、发帖或查询等操作时，都需要成为注册用户而不是游客，注册新用户也是论坛比较常用的功能，但是大多数情况下对于任何一个真实用户来说，注册用户也只是只做一次的事情，只需要单击注册后输入相关用户名和密码即可完成用户的操作，而不会每次使用系统新注册用户。

通过VuGen录制上述操作后，检查对应的脚本，回放这些脚本均可以成功并且没有出现漏录协议交互的情况，那么就可以认为该系统的性能测试是能够使用LoadRunner工具进行的。如果出现脚本回放失败，并不能说明无法使用LoadRunner进行性能测试，需要再参考下面的系统相关信息来进一步确认。对于基于HTTP的应用来说，LoadRunner已经非常成熟了，所以很少会发生在基于HTTP的应用中无法进行性能测试的情况。

3. 获得系统相关信息

当脚本回放出错时，某些情况是由于无法录制到某些操作导致回放失败，而大多数情况是由于系统中存在某些动态数据，导致操作无法达到预期的效果，这时需要通过关联来解决动态数据的问题。

那么什么数据需要关联，什么数据需要关联呢？这要求我们熟悉系统业务流程。常见系统的动态数据无非就是session和一些页面参数，通过询问开发或系统设计人员来了解动态数据的产生规则和使用方式。

在需要测试的Discuz论坛中，可以在操作中发现一些常见的动态数据。例如论坛的帖子编号、用户编号、板块编号等，而并没有session这种复杂的检查手段出现（可以通过对相同对象的多次操作，对比请求和返回的区别来识别动态数据）。

而在Phpwind中我们知道需要对verify和_hexie这两个数据进行关联，这两个属性会辅助验证发帖。

当完成了协议的确定、业务的熟悉和相关信息的收集后，接着可以对脚本进行简单的开发了，那么是不是需要把用户所有的行为都进行模拟呢？非也，性能测试并不是要求德智体美劳全面发展，而是强调核心竞争力，接着要做的是对性能测试的目标进行定义，避免性能测试的眉毛胡子一把抓。

1.1.2 定义测试目录

作为任意一个测试来说，了解了被测对象后，接着就需要了解用户的测试目标或者叫做需求。不是在开发前已经和用户确认生成SRS（需求规格说明书）了吗？其实问题就出在我们总认为有了SRS软件就能够做出来了，但是实际情况是一方面SRS并无法包含所有的用户需求，另一方面在设计SRS的时候总会忽视在性能方面的需求，即在设计阶段性能隐患就被植入了软件。

用户自身是无法提供准确有效的需求的，所以作为需求中的性能测试，需要性能需求分析工程师对其进行显式和隐式的分析，得到准确清晰的性能需求，当需求被确认后我们就能知道性能测试该测什么了。

✔ 通过定义测试目标需要知道的是用户想要什么。

那么如何获得性能需求呢？在此之前请先考虑一个问题：上海铁路人民广场1号线站台和换乘大厅应该修建多宽？

乍看一眼，你可能觉得这是一个功能需求，怎么可能和性能相关呢？但这个确实是性能问题，如果换乘的楼梯修建过窄，会导致大量乘客无法疏散出月台引起事故，而如果修建过宽又会带来不必要的浪费，合适的疏散能力就是性能的吞吐量指标。

可能有些朋友会说，我没去过上海，也没有坐过地铁，如何知道这个性能是多少呢？确实，很多时候我们对用户所需要的系统闻所未闻，现在需要我们来做性能需求定义性能测试的目标不是无稽之谈么？那么按照这个道理来说，做性能需求分析的人都应该是业务专家，从某些角度来说需求分析本来就是需要对业务或技术的专家才能担当，但并不是说没有简便入手的方法，对于这种情况，可以通过一下几个方法来获取系统的性能需求。

1. 通过用户提供的数据进行分析

用户永远是需求的最后确认人，通过用户介绍和提供相关数据是分析系统性能需求最直接也是最简便的方式。例如用户想要新建一个系统，来将公司的业务无纸化，那么他会提出相关的要求，例如容量、响应时间、并发量、服务器资源等。而作为实现方，当性能需求分析工程师将用户的需求进行整理后，需要参考以前的项目或相关信息去确定该需求是否合理可实施，进一步和用户协调制定合理有效的性能需求，已达到双赢的结果。

例如，这里有一个OA系统的客户数据，整个公司有500个用户会使用这个系统，主要是在上面完成各种订单的内部处理，每笔业务的提交大概平均要15分钟，每个用户每天大概要提交20笔订单，高峰期时会有33个订单的提交量。整个公司大概有400人事负责订单提交的，还有50个用户负责订单的审查，每个订单都会被2个审查人员复审，复审的时间平均为5分钟。

通过整个客户信息我们能给出什么样的建议和性能需求呢？用户并不了解具体的性能指标，而只能提供业务数据，但是我们在这个业务数据中可以和用户确认一些事情来帮助我们了解性能需求。

在这里我么知道有400个用户在线提交订单，每个订单的提交平均速度是15分钟，而全天每个用户的订单量是20~33笔。通过这个数据我们大概可以计算出订单处理这个模块所需要的系统吞吐量。按照最悲观的考虑方式，以500个用户全部都做订单提交操作，每个用户的提交时间按照10分钟~12分钟较快的模式来计算，那么可以得到系统的处理能力需要达到500*60/10=3000笔业务/小时。进一步计算也就是50笔业务/分钟，每秒不到1笔业务，但是在这里我们并不能按照平均值来计算，这里需要适当地放松，避免多用户并发操作时系统出现问题。

所以需求应该定义为：系统支持500用户并发操作订单提交操作，提供每小时3000笔业务以上的操作能力，单位时间的处理能力大于10笔业务/秒（这个数据可以自己先进行性容量测试后再做确定，参考系统日志中得峰值数据，一般来说峰值数据是按照平均业务的10倍来计算的），标准处理能力下响应时间在2s以内，普通负载下10用户并发响应时间在3s以内，50用户以内的大业务并发响应时间在5s以内。按照每笔业务50个数据字段来计算，一笔业务需要使用500KB（带附件）的数据量，系统对于100Mb/s带宽的设计能够支持20个用户并发提交订单（不包含其他业务的带宽需要），在数据库中每存放一笔订单大概需要开销1MB的磁盘空间，按照每小时3000笔业务的基础加上8~10小时的标准工作时间，所以每天的业务应该有30000笔，需要开销3GB的磁盘空间。

当拥有这样一个性能需求时，如何进行性能测试，如何设计场景，如何评估服务器处理能力，如何确定服务器配置及容量是不是已经清晰了很多。

2. 通过系统日志

当进行旧系统升级的时候，历史数据即系统日志的方式是获得真实用户需求最有效的参考数据（对于峰值并发量的计算通过日志才是最可靠的）。作为常用的Web服务器IIS、Apache或者Nginx，当用户通过客户端发送请求到Web服务器的时候，都会访问日志中记录下来。

IIS日志设置的方法说明如下。在IIS中找到需要的网站，打开日志功能，如下图所示：

IIS默认支持以下4种日志格式：

Microsoft IIS 日志文件格式。

 信息记录在以逗号分隔的ASCII文本文件中。

数据是固定的，不能自定义该日志。

单个传输有多条记录。

NCSA公用日志文件格式。

信息记录在使用（美国）国家超级计算技术应用中心（NCSA）格式的ASCII文本文件中。

数据是固定的，不能自定义该日志。

单个传输有多条记录。

W3C扩展日志文件格式。

W3C（万维网联合会）扩展日志文件格式是SMTP服务以及其他IIS服务的默认日志记录格式。

数据是变化的，可以选择要跟踪的内容。

此种格式是限制日志大小很好的选择。

信息记录在ASCII文本文件中。

这种格式包括某些仅适用于Web和文件传输协议（FTP）服务的字段选项。

单个传输有多条记录。

ODBC日志记录

 使用此格式钱，必须建立一个开放式数据库连接（ODBC）兼容的数据库。

信息记录在数据库中。

单个传输有多条记录。

如果使用IIS作为Web服务器的话，建议使用W3C格式。这里可以通过格式后的选择字段功能为日志添加监控属性，如下图所示：

监控的数据越多，对后期分析可以提供的支持就越强。

Apache日志设置的方法说明如下。

 Apache的访问日志格式支持自定义，打开Apache下的httpd.config文件，使用LogFormat命令来查询系统默认的日志格式，也可以自行定义需要的日志格式。

在httpd.config文件中找到以下内容：

<IfModule log_config_module>     LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined# 日志的格式    LogFormat "%h %l %u %t \"%r\" %>s %b" common# 普通访问日志格式<IfModule logio_module>LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio </IfModule># 默认站点访问日志配置CustomLog "logs/access_log" common# 访问日志路径 common#CustomLog "logs/access_log" combined # 访问日志路径 combined （复合日志）</IfModule>

我们先来简单介绍以下LogFormat的使用格式。以下是一个典型的记录格式：

LogFormat "%h %l %u %t \"%r\" %>s %b" commonCustomLog logs/access_log common

它定义了一种特殊的记录格式字符串，并给它起了个别名叫common，其中的“%”指示服务器用某种信息替换，其他字符则不做替换。引号（）必须加反斜杠转义，以避免被解释为字符串的结束。格式字符串还可以包含特殊的控制符，如换行符“\n”、制表符“\t”。

CustomLog指令建立一个使用指定别名的新日志文件，除非其文件名是以斜杆开头的绝对路径，否则其路径就是相对于ServerRoot的相对路径。

上述配置是一种被称为通用日志格式（CLF）的记录格式，它被许多不同的Web服务器所采用，并被许多日志分析程序识别，它产生的记录形如：

127.0.0.1 - frank [19/Aug/2000:14:47:37 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

记录各部分说明如下：

127.0.0.1 （%h）

这是发送请求到服务器的客户IP地址。如果HostnameLookups设为On，则服务器会尝试解析这个IP地址的主机名并替换此处的IP地址，但并不推荐这样做，因为它会显著拖慢服务器，最好是用一个日志后续处理器来判断主机名，比如logresolve。如果客户和服务器之间存在代理，那么记录中的这个IP地址就是代理的IP地址，而不是客户端的真是IP地址。

- （%l）

这是由客户端identd进程判断的RFC1413身份（identity），输出中的符号“-”表示此处的信息无效。除非在严格控制的内部网络中，此信息通常很不可靠，不应该被使用。只有在将IdentityCheck指令设为On时，Apache才会试图得到这项信息。

frank （%u）

这是HTTP认证系统得到的访问该网页的客户标识（userid），环境变量RENOTE_USER会被设为该值并提供给CGI脚本。如果状态码是401，表示客户未通过认证，则此值没有意义。如果网页没有设置密码保护，则此项将是“-”。

[19/Aug/2000:14:47:37 -0700] （%t）

这是服务器完成请求处理时的时间，其格式是：

[日/月/年:时:分:秒 时区]日=2个数字位月=3个字母位年=4个数字位时=2个数字位分=2个数字位秒=2个数字位时区 = （+正 | -负） 4个数字位

可以在格式字符串中使用%{format}t 来改变时间的输出形式，其中的format与C标准库中的strftime()用法相同。

"GET /apache_pb.gif HTTP/1.0" （\"%r\"）

引号中是客户端发出的包含需要有用信息的请求行。可以看出，该客户的动作是GET，请求的资源是apache_pb.gif，使用的协议是HTTP/1.0。另外，还可以记录其他信息，如格式字符串"%m%U%q%H"会记录动作、路径、查询字符串、协议，其输出与"%r"一样。

200（%>s）

最后这项是返回给客户端的不包括响应头的字节数。如果没有信息返回，则此项应该是“-”，如果希望记录为“0”的形式，就应该用%B。

首先使用LogFormat命令LogFormat "%h %l %u %t \"%r\" %>s %b" common 定义日志格式，然后再通过CustomLog命令CustomLog "c:/logs/access.log" common 为日志设置存放的地址。这样就完成了 Apache 日志的设定工作。

Nginx日志相关指令主要有两条：

log_format，用来设置日志格式。access_log，用来指定日志文件的存放路径、格式和缓存大小。

1）log_format格式

log_format name（格式名称）格式样式（即想要得到什么样的日志内容）

默认的示例：

log_formatmain$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for";

注释如下。

$remote_addr: 与$http_x_forwarded_for 一起用以记录客户端的IP地址。

$remote_user: 用来记录客户端用户名称。

$time_local: 用来记录访问时间和时区。

$request: 用来记录请求的URL和HTTP协议。

$status: 用来记录状态：成功是200。

$body_bytes_sent: 记录发送给客户端文件主体内容大小。

$http_referer: 用来记录从哪个页面连接访问过来的。

$http_user_agent: 记录客户浏览器的相关信息。

通常Web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add得到的IP地址是反向代理服务器的IP地址。反向代理服务器在转发请求的HTTP头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。举例如下：

log_formatmylogformat $http_x_forwarded_for- $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent";

2）用access_log指令日志文件存放路径

用了log_format指令设置了日志格式之后，需要用access_log指令指定日志文件的存放路径。

access_log path（存放路径） format（自定义日志名称）

示例：

#access_loglogs/access.log main;

我们用log_format定义了一个mylogformat的日志，可以写成这样：

access_loglogs/access.log mylogformat ;

如果不想启用日志；

access_log off ;

在定义日志目录要注意的是，Nginx进程设置的用户和组必须有对该路径创建文件的权限，假设Nginx的usr指令设置的用户名和用户组都是www，而logs目录的用户名和组都是root，那么日志文件将无法被创建。

接着让用户在正常情况下使用一段时间这个配置了日志的系统，就能得到大量的访问数据，以便进行下一步的日志分析工作。

什么是日志分析？虽然现在得到了用户的访问日志，但是面对数以亿计的用户请求记录，如何才能从这众多的数据中找到想要的数据，这个时候就需要通过日志分析工具来实现了，这也是为什么在前面需要规范日志格式的原因，否则工具会不支持自定义的日志格式。

日志的分析工具其实也很多，这里介绍的是WebLog Expert。作为一个强有力的日志分析工具，WebLog Expert能够分析网站的流量记录，将原始的流量记录分析出Activity statistics、Access statistics、Information about visitors、Referrers、Information about errors等基本而重要的流量信息，帮助你了解网站的使用情况，另外它同时支持IIS和Apache日志也是我们选用该软件的原因之一。

整个工具的使用比较简单，打开WebLog Expert，单击新建按钮，创建一个新的分析日志项目，填写项目名称和服务器地址后，选择事先准备好的日志文件，如下图所示：

 一般来说IIS的日志都默认存放在inetpub\logs\LogFiles地址下，在这个目录下会看到以W3SVC1开头的目录，该目录中有很多.log文件，这些文件就是用户访问IIS所留下的访问日志。如果是Apache或Nginx日志请检查主配置文件中定义的日志存放地址。

添加完成后，单击下一步按钮，确认需要分析的时间段，如下图所示：

 WebLog Expert支持多种时间过了规则，由于这里是里的日志比较小，所以我们选择All activity选项对日志中所有的时间段进行分析，后面的跟踪类型和过滤规则一般不设置，接着转到最关键的地方，如下图所示：

使用日志分析工具的核心就是生成的报告能帮助我们挖掘到那些感兴趣的内容，这里WebLog Expert支持输出HTML/PDF/CVS等格式的分析报告，还可以自定义输出的格式和分析报告的内容，选中Custom report content后可以自定义需要输出的报告内容，如下图所示： 

系统提供了大量的报告选项可以根据情况进行定义。当这些都做完后，单击完成按钮，结束日志分析设置。单击菜单中的Analyze按钮，稍等片刻便会生成一份详尽的日志分析报告（用户行为记录），如下图所示：

通过这份报告，可以得到系统当前的负载情况，如果能够结合同时期的系统资源日志和系统错误日志，就能够得到非常珍贵的性能测试数据（系统在过去的负载情况以及对应资源的利用率和响应时间），为后期的性能调优提供基准数据。接下来看看一个真实的系统所得到的日志数据，如下图所示： 

 这是某个论坛系统在2008年8月19日至2008年9月1日的系统访问日志分析报告，整个日志大约12GB，分析这个日志文件也需要点时间。

通过这个简单的Summary可以粗略地了解系统当前的一些基础性能指标。在大约两周的时间内，整个系统共有人访问，共产生次点击，总带宽使用1849.27GB。

是不是得到这些数据就能做性能测试了呢？非也！平均数据和总计数据其实对于做性能测试并没有什么用处，因为访问并不是平均的，从测试的角度，更在意峰值数据。整个系统只要能够瞒足用户在真实访问下的峰值数据，就能保证整个系统能够满足用户的性能需求。所以一般桥或堤坝是按照50年一遇标准或者100年一遇标准来修建，其实就是根据历史记录获得峰值的情况，按照这个标准来衡量性能。

那么如何获得峰值数据呢？我们来看看这份日志报告中还能得到什么。首先如果想知道在这段时间内，哪一天的访问量是最高的，可以找到日志中的Activity Statistics标签，这里提供的都是访问量的统计，打开该标签即可得到在这段时间内系统的访问数据。首先映入眼帘的是每日访问量、每日点击量、每日带宽统计表和生成这些图所使用的数据表。

 

 

 通过分析这些数据，可以轻松地获得系统的每日峰值吞吐量和峰值访问量，从而建立性能测试需求的指标（目标场景的依据），另一方面也得到了用户访问系统的真实情况（手工场景），那么是不是可以参考这个数据来生成场景了呢？

无论对于目标场景还是手工场景来说，上面的这些数据以天为单位还是大了一些，无法得到更精确的数据，不利于性能分析。那么继续往下看日志分析，即可得到每天各小时访问量统计图，如下图所示：

 当看到下图的时候，大家肯定有一种豁然开朗的感觉，原来想得到的信息就是这个啊。在下图中可以看到一天中各个时间点上的系统访问量，在这个周期中可以发现对于每天来说用户的访问量并不是平均的。

通过日志分析可以发现一天的访问量是出现在图上的0:00（注意日志时间是根据该操作系统的系统时间设定的，按照时差转换为中国时间需要倒扣8小时），也就是北京时间PM8:00，这就是系统的峰值数据，在这一个小时中收到的负载量如下表所示：

HourHitsPage ViewsVisitorsBandwidth(KB)00:00 - 00:592,679,676399,67341,440159,594,667

1小时内产生了260万的点击量、接近40的页面刷新、4.1万访问用户和159GB的带宽。这里可以计算一下系统有没有出现带宽瓶颈，如果系统是在机房托管，带宽为1000Mbps那么换算一下就是每秒提供120MB的宽带，换算成小时是MB的宽带也就是432GB/小时，所以还没有达到带宽峰值，没有明显的带宽瓶颈出现。那么什么时候会出现带宽瓶颈呢？

当系统的访问量达到600万点击量、120万页面刷新、12万在线用户的时候，带宽已经无法承受这些负载带来的带宽需求了，结果就是每个用户所能分享到的带宽降低，访问速度变慢。

通过以上数据可以得到最终的峰值性能需求（如果需要精确到分钟的峰值性能，那么该工具无法提供，可以自行编写程序对日志进行分析），另一方面场景设置中的手工场景已经可以设计了，只需要按照该日志的走势就可以得到场景模型生成Real-Life Scenario。

1）目标场景设计（预估系统扩张规模，预留20%增长空间）

在1小时内，系统承受5万用户在线、页面刷新48万次、点击量320万、带宽吞吐量191GB，在该负载下CPU以内存资源利用率低于80%，无明显磁盘网络瓶颈。

2）手工场景（Real-World Scenario）

根据日志中的用户访问趋势，可以设计得到如下图所示的Real-life Scenario（计算了20%的富余）。

3）手工场景（Basic Scenario）

通过日志得知了最大用户在线数，就可以得到Basic下的手工场景。设置用户最大访问量为5万用户，持续1小时，根据具体情况（设置负载生成速度和负载取消速度），了解在负载逐渐增加到5万用户的过程中，系统各资源是否走向瓶颈，在峰值负载下，获得系统的峰值性能数据，并验证能否满足用户需求。

除了目标场景和手工场景的信息以外还能获得什么信息呢？对于性能测试来说，其实并不需要整个系统的所有功能都达到某个性能，因为有些功能用得多，那么性能要求就高，而某些功能的使用率非常低，性能方面自然就不做要求。通过日志可以得到哪些功能和页面被经常访问，以确定整个系统承受负载的功能集中在哪里，性能测试脚本的目的性会更强。

打开日志的Access Statistics功能，即可得到整个系统用户访问最多的页面分析，还有系统中的文件、图片、进入系统页面、用户在系统中的操作路径等信息。通过这些信息可以更加准确地编写有效的测试脚本来模拟大多数用户的行为，确保性能负载的真实性。后期的页面优化也可以参考这里的常用访问记录。

在Daily Page Access图中可以找到系统被访问最多的页面（业务），如下图所示：

 Visitors表示访问系统的用户信息，对于系统来说还需要考虑访问用户的所属地，由于各地的网络发达程度不同，并且还有跨国访问的问题，那么这里还要考虑模拟用户的地区性（可以通过设置带宽速度来模拟真实用户访问系统的感受）。

带宽较小及网络延迟较高的用户，自然访问时间会比较长，而和服务器同一个城市的用户自然访问比较快。在下图中可以发现系统的用户来着中国，如果希望进一步得到中国城市访问量的分布可以导出数据根据IP规则进行进一步分析。这里列出系统访问量最高的20个国家和地区记录，如下表所示：

 

对我们来说，在确定了系统的主要客户群以后，性能测试也要兼顾这些地区的网络特点进行测试，从而得到真实的响应时间，避免出现自己访问很快，但是主要客户群访问很慢的尴尬情况。

最后在日志中还能得到系统运行的错误统计。这些错误日志可以帮助我们分析系统存在的问题，另一方面，当进行性能测试后，也可以通过它来了解系统出错的原因。

衡量性能测试的有效性和真实性也可以通过日志来实现。如果性能测试后得到的日志分析结果和真实的历史日志数据接近，那么就可以说明性能测试几乎完全模拟了用户的行为，性能负载生成是成功有效的。所以日志是一个非常大的宝库，当做好数据挖掘后，可以从中得到大量的需求，来指导性能测试的设计和执行。

有一点请不要遗忘，就是系统负载是动态的。某些系统的客户是固定的，不会有太大的变化。例如，公司内部采用C/S架构的系统，那么这种系统负载是可控的，而如果是一个对外访问的B/S架构的网站，对性能测试的数据有一个容量规划，确保系统在不可控的增长下也能正常使用。而用户的增长可以参考日志的变化规律，通过一个模型来预估未来的容量。

根据过去日志得到的2008年8月最高访问时间段访问量，再按照2008年8月月度访问量对比2011年8月份月度最高访问量，可以推算出现在我们需要进行性能测试的峰值数据应该为（20%富余处理能力保留）：

在一小时内，系统承受10万用户在线、页面刷新96万次、点击量640万、带宽吞吐量382GB，在该负载下CPU及内存资源利用率低于80%，无明显磁盘网络瓶颈。

进一步我们可以通过策略来对上线环境进一步的预估。

通过硬件评测一般每台服务器支撑动态请求1000个/台/s，每台服务器支撑静态流量400M/台/s。

现在知道系统1小时有96万次的页面刷新，默认每个页面刷新包括1~3个动态请求，那么每秒的并发请求最大为(*3)/(1*3600)=800个/s，按照峰值并发为平均并发10倍来计算，最大并发量为8000个/s，所以8000/1000=8大约需要8台服务器来完成动态请求处理。

预计每个页面包含img/js/css/50个静态文件，平均并发=/(1*3600)*50=13333/s，峰值并发约/s。

预计每个文件5Kb，平均带宽=/(1*3600)*50*5*8约0.521Gb/s，峰值带宽约=5~5.5Gb/s，根据静态容量指标需要13~14台服务器。*8的作用是单位换算从Kb换做KB。

根据运营经验值，页面：图片：素材=14%：64%：22%，推导各业务模块带宽=页面13G：图片59G：素材20G，再通过各业务模块的容量指标推导需要多少台接入服务器，根据接入服务器反推需要多少中间层服务器。

根据业务监控数据，电信：网通=2:1，推导电信、网通个需要多少带宽，在推导平均分布到现有电信、网通IDC，根据每个IDC需要支撑的带宽，反推每个IDC需要上架构多少服务器。

3. 通过参考同类业务

如果需要新建一个项目，而从前有没有想关的历史记录，前面通过日志的方法就不能使用了，不过这时可以参考一下同类的业务。

虽然是第一次做这类项目，但是并不代表别人没有做过，可以参考一下别人是怎么做的。

例如：如果希望自己做一个51Testing规模的技术论坛，那么在进行性能测试时需要达到的性能指标是什么呢？答案很简单，打电话给51Testing说想要购买一个首页广告位，了解一下访问量和相关业务即可。

4. 通过80/20原则

80%的功能只会有20%的用户访问，反过来也可以说80%的用户只使用20%的功能。对于性能测试来说并不需要确保整个系统所有的功能都能完全满足性能需求，而是应该把精力集中在用户最常使用的功能上。

通过这个规则结合前面的日志或者同类项目用户的访问特征，可以对系统的功能进行划分，将不太常用的功能删除，得到最终的性能需求。

通过上面几种方法还可以根据国家或行业规范标准来确定需求，从而得到Discuz或Phpwind论坛的性能测试目标，包括目标场景和手工场景的场景模型，以及性能测试的主要业务。

到了这里我们再回来看看最开始提的问题，上海地铁人民广场1号线站台和换乘大厅的楼梯应该修建多宽？

现在知道怎么确定这个需求了么？接着我们来计算一下这个需求应该怎么写。

楼梯的主要作用是解决换乘大厅和地铁月台两个系统的接口，如果不能及时将月台上的乘客通过楼梯输送到换乘大厅没那么就会导致很严重的月台拥堵，甚至出现地铁上的顾客下不了车，月台上的顾客上不了车的情况。这里我们不考虑月台和换乘平台的性能瓶颈，假设这两个系统都不存在问题，那么楼梯要解决的就是讲月台上的乘客及时送上换乘大厅。

到底有多少乘客要送上换乘大厅呢？这里我们计算一下地铁到站的频率，根据百度百科（）和新华网新闻（），可以查询到的结果高峰期发车频率在2分44秒，而每节车厢设计容量320人（高峰时期能挤入400人），也就是说一列地铁（8节）大概能够容纳3200人，由于人们广场站是双向的，所以平均1分22秒就会有一列地铁导致下车。假设到达人们广场站有65%的乘客需要下车换乘（这里需要现场监控评估），也就是说楼梯需要在1分钟22秒内将3200*0.65=2080名乘客从月台上疏散。这里还是理论情况，因为地铁不会那么平均到站，经常会出现拥堵导致多辆地铁连续到进站的情况，由于前面月台设置了足够的处理能力，所以这里我们不考虑月台放不下那么多乘客的情况。对乘客的疏散能力做一个小的限制，将处理时间从1分22秒限制到1分10秒（也就是70秒），提供12秒的富余空间。

那么70秒如何疏散2080名乘客呢？按照月台到换乘大厅有4个楼梯来计算，每个楼梯平均要在70秒疏散520名乘客，约等于8乘客/秒，扣除自动扶梯的每秒2乘客处理能力，我们只需要设计一个能同时6乘客上楼的楼梯即可。按照一部自动扶梯和6人并排上楼的楼梯为基础，我们可以得到楼梯的设计宽度约为4米，这里不包括两部自动扶梯的情况和有乘客需要从换乘大厅下到月台的情况，如果包含这两点，那么楼梯设计应该在7米以上，如果乘客过多，需要限制下月台的人数，避免月台出现无法容纳的问题。

有时候经常在地铁上有人抱怨上海的地铁怎么拥挤，提议应该多开几部地铁，想法虽然是好的，但是这样的做法并不一定能得到应有的效果。因为表面的瓶颈是在地铁的数量上，但隐藏的瓶颈是在月台的大小疏散能力，否则车再多都在等人下车上车也快不起来。另一方面不断地减少地铁班次的间隔时间从技术角度不会有太大的问题，但是一旦系统在超设计负载下出现某些Bug，那么“轻微性碰擦”的事件就在所难免了。

解决地铁拥堵的方法一般都是采用合理的线路安排，例如，4号线改变了很多张江男女的路线，为1、2号线中心地段提供了大量的分流。如果需要解决上下车效率的问题，那么8号线的左右两边门一起开，是一个非常好的办法，也许在不远的将来我们会看到1、2号线人民广场站会出现两边一起开门的情况（实施难度和成本有点高）。

通过性能需求分析我们需要达到以下目的：

知道用户会做什么。

知道用户怎么做这件事情。

知道多少用户做这件事情。

知道对呀的性能指标是什么。

性能需求是需求分析人员需要提供的重要文档之一，作为性能测试工程师来说也需要具备一定的性能分析及评审的能力。

1.1.3 明确定义概念

通过上面的性能需求分析得到了关键的用户需求规格，接着需要对需求规格转化成性能测试工具中的目标。

✔  明确定义概念需要知道测试的最终目标是什么。

在性能测试中需要的目标主要为在一定的负载下系统主要业务操作的响应时间、服务器的资源占用率、不同业务的最大吞吐量、系统所能支持的在线用户数以及主要业务的并发处理能力。另外也可以使用LoadRunner自带SLA的一些指标来做参考项，如系统在负载过程中的错误产生情况和响应时间的变化情况，以及系统在整个性能测试过程中的总点击量、平均每秒点击量、总带宽使用量和平均每秒带宽使用量。

这里需要明确的内容包括：

系统真实环境平台的架构及软硬件标准。

需要进行性能测试的模块以及对于案例。

脚本开发中可能需要解决的技术。

业务完成与否的判断标准。

相关信息的监控策略。

场景模型的定义。

对系统负载后的结果预估。

明确相关的性能测试目标后，即可开始测试计划文档的编写工作。

1.1.4  编写性能测试计划

编写性能测试计划的目的是为了整个性能测试阶段的管理工作和技术工作提供指南，在测试计划中需要明确测试的内容和范围，为评价系统提供依据，此外还需要说明对设备及人员资源的要求，依据测试结果的评价指标。

如果被测系统比较简单，那么可以在性能测试计划中直接明确测试的方法及对象，而如果是一个比较大的项目，建议使用性测试方案文档来说明性能测试的实施方法。针对于我们这次所需要测试的项目情况，将前面的内容整理后可以得到以下的而测试计划。

Phpwind 系统性能测试计划

文档目的

描述Phpwind性能测试流程、范围、环境、风险等因素作为性能测试实施依据。

项目背景介绍

Phpwind作为国内知名的通用型系统品牌，凭借其产品的非凡速度、强大的功能模块、卓越的负载能力、领先的技术优势、富于创新的研发团队及自主版权的核心竞争力，为众多行业门户、专业型站点提供最有价值的方案和技术保障。致力于推动互联网信息的交流与共享，将开源共享与合作创造财富的理念作为公司的发展宗旨。

Phpwind Board（中国国家版权局著作权登记号为2004SR06082）拥有众多原创的核心技术，包括独创的模块设计思想、成熟的数据库设计理念、索引数据文件的利用及其算法、文件读写稳定性算法、数据库索引负载均衡算法、安全防护技术等。基于Phpwind的优异性能，公司成为浙江省Linux专业委员会会员单位，并获得Linux产品测评证书。

通过这次性能测试，为评估Phpwind8.5和DiscuzX2论坛之间的优劣，并获得允许该论坛的最佳配置，提供参考数据及结论。

术语及缩写

性能测试（Performance Testing）：在一定的负载情况下，西柚的响应时间、吞吐量等特性是否满足特定的性能需求。

负载测试（Load Testing）：在一定软件、硬件及网络环境下，在不同虚拟用户数量的情况下运行一种或多种业务，测试服务器的性能指标是否在用户的要求范围内，用于确定系统所能承受的最大用户数、最大有效用户数以及不同用户数下的系统响应时间和服务器的资源利用率。

压力/强度测试（Stress Testing）：在一定软件、硬件及网络环境下，通过模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下长时间连续运行，已测试服务器在高负载情况下是否能够稳定工作。

配置测试（Configuration Testing）：在不同的软件、硬件以及网络环境下，在一定数量虚拟用户运行一种或多种业务，获得不同配置的性能指标，用于选择最佳的设备及参数配置。

基准测试（Benchmark Testing）：在不同的软件、硬件以及网络环境下，模拟一定数量虚拟用户运行一种或多种业务，将测试结果作为基准数据，在系统调优或者系统评测过程中，通过运行相同的业务场景比较测试结果，确定调优是否达到效果或者为系统的选择提供决策依据。

LAMP、LNMP、LANMP（LNMPA）：LAMP是Linux+Apache+MySQL+PHP的缩写，是一种常见的PHP架构。LNMP是Linux+Nginx+ MySQL+PHP的缩写，由于Nginx在静态页面处理上相对Apache有超高的处理能力，所以现在更为流行Nginx作为Web服务，但PHP模块无法直接在Nginx上运行，所以是单独作为CGI模式运行的，相对来说没有Apache整合模式运行稳定，容易出现502错误。LANMP（LNMPA）是结合了LAMP和LNMP的有点诞生的新型架构，使用Apache模式运行动态页面，使用Nginx运行静态页面，从而获得性能和稳定性的最大化收益。

CentOS：CentOS（Community ENTerprise Operating System）是Linux发行版本之一，它来自Red Hat Enterprise Linux依照开放源代码规定释出的源代码所编译而成的。由于出自同样地源代码，因此有些要求高度稳定性的服务器以CentOS替代商业版的Red Hat Enterprise Linux使用。两者的不同，在于CentOS并不包含封闭源代码软件。

输入

《项目计划文档》

《性能需求规格说明书》

《系统架构设计文档》

《系统测试计划》

入口标准

无

系统运行环境

网络拓扑图

软硬件配置

设备名称

硬件配置

软件配置

备注

服务器

CPU：

I7 930 2.8GHZ 133x21

内存：

DDR3 1333 2GB X 3（三通道）

硬盘：

ST 7200.12 1TB（7200转\32MB 缓存）X2 RAID 0

网卡：

Intel10/100/1000 自适应

操作系统：

Windows 7 X64 SP1 6.1.7601

VMware8.0.0 build-47178

CentOS 5.5. 32位

CentOS 5.6. 64位

Web服务：

Apache

Nginx

数据库：

MySQL

监控工具：

Nmon

Spotlight

Rpc.rstatd

所有测试环境均在虚拟机下完成，虚拟机默认配置均为双CPU双线程，2GB内存

负载生成器

CPU：

Inter I3 3210

内存：

DDR3 1333 6GB

硬盘：

500GB（7200转）

网卡：

Realtek PCle GBE Family Controller

操作系统：

Windows 2008 R2 SP1

负载生成工具：LoadRunner 11

 

测试内容

根据性能测试需求分析，在本次测试中我们需要对Phpwind论坛的浏览、发帖、注册及查询功能进行性能测试，评估LAMP、LNMP、LANMP三大主流架构在CentOS系统32位及64位下的运行表现，确认何种框架更加适合运行论坛系统，进一步得到各个功能在一定平台下的最大数据处理能力。最终在最优平台下对比DiscuzX2论坛执行效率，得到最佳硬件平台下的运行对比。

非测试内容

由于以下功能在真实情况中使用较少，并对响应时间无明确需求，故不进行测试：

用户间的短信息功能

帖子的移动管理功能

论坛后台的管理功能

角色和职责

角色

资源数量

职责

备注

测试经理

1

跟踪监督性能测试项目进度

审核性能测试报告

高级性能测试工程师

1

撰写性能测试计划

分析性能需求，制定性能测试方案、测试用例

设计性能测试场景及性能测试平台

辅助开发人员修改性能缺陷

撰写测试报告

性能测试工程师

1

开发性能测试脚本

执行性能测试场景

搭建测试环境

性能测试工具列表

测试工具

版本

许可

用途

备注

LoadRunner

V11

Web 10000 Vuser

性能测试

SVN

V1.6.5

配置管理

Httpwatch

V7.0

HTTP分析

Word

V2007

撰写测试报告

Visio

V2007

绘制流程图

Project

V2007

跟踪项目进度

Spotlight

CentOS及MySQL监控

Nmon

CentOS监控

Nmon analysis

Nmon日志分析

RPC.rstatd

CentOS监控

进度安排

任务名称

起始时间

结束时间

工作日

资源

测试计划

2011-12-9

2011-12-12

2

测试经理、高级性能测试工程师

测试方案

2011-12-13

2011-12-15

3

高级性能测试工程师

测试用例及脚本开发

2011-12-16

2011-12-21

4

高级性能测试工程师、性能测试工程师、开发工程师

测试环境搭建

2011-12-22

2011-12-23

2

系统管理员、运维人员、高级性能测试工程师

测试执行

2011-12-26

2012-1-4

8

高级性能测试工程师、性能测试工程师、架构设计师、运维人员、数据库管理员

测试报告总结

2012-1-5

2012-1-6

2

高级性能测试工程师

Project甘特图

 

出口标准

获得各平台下的测试数据，评估得到最佳运行平台。

评估得到Phpwind85在最佳平台上的处理能力峰值。

压力测试连续12小时无故障。

在最佳平台上对比获得Phpwind85及DiscuzX2论坛数据。

测试结果达到预期目标，系统满足用户处理能力及稳定性需求。

交付物

序号

交付件名称

交付件编号

备注

1

《性能测试计划》

2

《性能测试方案》

3

《性能测试用例》

4

《LoadRunner性能测试脚本》

LoadRunner格式

5

《LoadRunner脚本业务报告》

LoadRunner格式

6

《LoadRunner性能测试场景及测试结果》

LoadRunner格式

7

《性能测试报告》

风险

受环境限制，无法在测试环境中模拟系统真实上线环境下LVS负载均衡及CDN环境，测试环境服务器配置与在线架构有一定误差，故该结果无法完全代表在线运行情况。

假设

无

通过性能测试计划对性能测试的范围、资源、时间任务安排进行确定以后，接着需要定义性能测试方案为性能测试的执行提供策略。

1.1.5 编写性能测试方案

编写性能测试方案的目的是为整个性能测试阶段的执行内容及策略进行详细说明。

》》》推荐阅读《《《

1、性能测试学习笔记-场景设计

2、Web站点性能调优完全攻略

3、应用系统性能调优之性能分析

4、Windows监控——性能指标详解

5、性能测试的重要意义

6、软件性能测试的本质_致命版

7、性能分析流程及方法

8、性能测试流程

9、性能测试从需求分析开始

10、性能测试指标

11、双活数据中心揭秘之—DB2 PureScale

12、循序渐进学习oracle

13、软件项目管理中的十个误区

14、功能测试方法总结及常见面试问题

15、MQ来账通道及队列配置

16、Linux命令大全整理

17、JMeter工具简单介绍

18、性能瓶颈分析方法

19、性能测试-LoadRunner操作流程之一

20、性能测试-LoadRunner操作流程之二

21、性能测试-LoadRunner操作流程之三

22、性能测试-脚本编写之一

23、性能测试-脚本编写之二

24、性能测试-脚本编写之三

25、性能测试-性能调优之一

26、性能测试-性能调优之二

******免责声明******

本内容完全免费，全部来自互联网和项目实践经验，转载内容是出于传递更多信息之目的，仅供读者参考，若有来源标注错误或侵犯了您的合法权益，请立即与我们联系，我们将在第一时间核实并处理，非常感谢！

获取更多精彩资源、参与更多活动，敬请关注微信！