步骤四 为导航路径或模拟用户识别唯一性的数据

很不幸，光是导航路径不能提供所有的需要贯彻的负载模拟的信息。至于所有的可执行的负载模型，以下信息是需要的，包括：

用户在一个页面上停留多长时间？

每个页面需要什么样的数据？

用户在什么条件下变化导航路径？

下表提供了一个为电子商务应用提供识别唯一数据的例子。

需要考虑的事

在为导航路径或模拟用户识别唯一性的数据时，需要考虑以下关键事项：

• 性能测试一般需要消耗大量的测试数据，需要准备充足的测试数据；
• 重复使用相同的数据可能会导致无效的结果；
• 尤其是在设计和调试性能测试脚本的时候，可能会引起测试数据的过量负载，要提前检查，去掉干扰性能测试结果的一些垃圾数据；
• 在性能测试中要考虑到一些无效的数据。比如说，有的用户第一次输错了密码，第二次才输入了正确的登录了系统；
• 第一次登录的用户在页面上停留的时间要比经常使用该系统的用户停留的时间长；
• 最有可能的测试数据一般来自于真实的生产环境或者日志文件；
• 要考虑到客户端崩溃的情况。第一使用的用户要下载每个控件，而经常使用的用户则不需要多次下载，而且还有可能以前的一些操作结果存在缓存中。要考虑到他们的不同；

为关键场景确定导航路径

人的操作行为是不可预期的，网站一般提供多条路径到达相同的功能或者操作，相对较少数量的用户而言这一定是正确的：真实用户不仅会使用任何你想到的路径来完成他们的任务，他们也会创造出想不到的路径。用户完成某个操作的每条路径，在系统中都会形成不同的路。这些不同有可能是微不足道的也有可能是特别巨大的——除非是你来测试，不然没有办法确定。有很多办法确定你完成一个任务或者一个操作的导航路径，包括：

• Identify user paths within your Web application that are expected to have a significant performance impact and that accomplish one or more of the identified key scenarios.
• 阅读设计文档或者操作手册；
• 从日志文件中提取数据；
• 亲自尝试操作；
• 让别人来操作，看他的操作路径。

系统为用户可接受测试，beta 测试或者产品测试发布版本后，你就能够确定大多数用户是如何在被测系统中到达他要操作的功能。一般这样也是很不错的主意：把你的模型和真实情况相比较然后根据你发现的相似和不同来决定是否运行额外的测试。

需要考虑的事

• 当你为关键场景确定关键路径的时候，要考虑以下事项：
• 有些用户作为一个游客时可能操作了很多功能；
• 有些用户登录一次可能操作了很多次相同的功能；
• 可能有些用户在网站上作为游客没有真正执行任何功能；
• 导航路径一般可以通过页面标题来获得；
• 如果系统中页面标题不是很直观，那么可以系统给定的操作步骤来确定系统的导航路径；
• 和经常访问的用户不同，第一访问的用户一般会走一个不同的路径，在你的模型中应该考虑到这些不同和新老用户的百分比；
• 不同的用户操作习惯也会有很大的不同，有的操作登出，有的直接关闭窗口，也有的不管它让它自己超时，我们在考虑和估计session持续时间的时候一定要确保把这些因素考虑进去。

识别关键的用户场景

想要在性能测试中模拟用户可能的所有的操作，这是绝对不可能的，因此，不管你是从sever的日志中分析出来的，还是通过观察可用性研究的，还是从市场材料中得到的，甚至直接是靠猜的，你都有可能都是在把一些有限的尝试用到行为活动的数量中，或者为性能测试识别关键的场景。你会发现下面的有限尝试是非常有用的：

通过目标的暗示或规定来确定关键场景；

要包括最常用的操作；

要包括比较明显的操作；比如，一个用户可能仅仅在你的网站上注册了一次，因为感受体验不好，就再也没有来过。

要包括关键的业务。比如说，如果你的业务是依赖消费者提供收益，那么如果消费者不能提交订单那一定会出现损失，一定要保证这样的操作完成的很好。

要包括比较集中的操作。即使这些操作用到的很少，他们也会显著地影响性能。比如，有的业务是一个月在后台批处理一次，但这些操作会对前台想性能有很大影响。

要包括写在合同里的对性能有要求的操作，或者有权势的利益相关人的操作。

下面是电子商务系统的关键场景：

1、浏览；

2、创建用户账户

3、查询；

4、登录；

5、提交订单

需要考虑的事

在识别关键场景中要考虑到一下关键点：

• 要把没有人的系统或是后台批量进程考虑成和终端用户一样。比如，当用户正在执行操作的时候，有一个批处理程序正在运行更改订单的状态。在这种情况下，你需要计算这些进程，因为他们也要消耗系统资源。
• 一般来讲，web servers 是对应文本和图片的处理能力是非常有效的。带有平均大小的静态页面一般没有动态页面，表格和多媒体页面那么关键。

步骤一：识别目标

创建负载模型的目的通常重点在于确保测试场景是符合现实情况的，或者是特别设计一个测试以满足特殊的需求、目标或者性能测试的目的（更多的信息，请参看“如何确定最终用户数量的需求”以及“如何定义性能测试目标”--秀霞以后有时间会慢慢翻译）当识别目的的时候，你应该充分考虑到满足商业需求的目标，在模拟你的目标的时候。可以考虑一下关键问题：

• 当前或随着时间推移预期的业务量是多少？比如，在给定时间段内的订单是多少？其他操作时什么？比如查询的数量，浏览的数量，登录次数等等，支持订单顺序吗？

• 随着时间推移，业务量是怎样的期望？你的项目应该应该把将来的需要计算在内，比如，业务的增长，可能出现的企业合并，新产品的引入等等。

• 目前或者期望的负载峰值水平是什么？这个项目应该考虑支持这样的行为活动，这些行为活动支持销售或者其他关键业务流程，比如市场战役（诸如产品促销，搞活动等等-秀霞加），新产品上市，对时间敏感的活动比如证券交易所依赖于永不停歇的市场等等。

• 你期望多快达到峰值负载水平？你的预期应该把不是很常见的业务活动激增考虑在内，当一个事件发生后，对增长的需求组织调整有多快？

• 峰值的负载会持续多长时间？也就是说，在系统疲劳之前的资源的退让会持续多长时间？比如说，一个经济公告就可以引起货币外汇市场持续高负荷两到三天，而不是几个小时。

这些信息可以从web服务器的日志中获得，也可以从市场文档反映出的商业需求中获得，也可以从利益相关者那里获得。下面是一些在这个过程中被识别的目标：

• 确保一个或者多个模型可以代表峰值期望的负载（每小时产生的订单数）

• 确保一个或者多个模型可以表示出 “quarterly close-out” 区间使用模式和“典型营业日”使用模式的区别。（译者理解：有的系统只登录一次，可能查询一下或者操作一个功能就退出了，而有的系统则全天在线，比如柜台业务的操作的系统，早上登录，全天都在不停地执行操作）

• 确保一个或多个模型可以表示出业务或者市场项目可以在未来一年内运行的很好。

如果这些目标在项目的背景下是讲得通的，那么我们就认为是可以接受的。接下来要做的就是为取得的目标填充上必要的详细内容。

要考虑的事

在识别目标的时候要考虑到以下的关键点：

• 创建一个负载模型过程中的吞吐量，记得和团队分享你的假设条件和草稿，索求他们的反馈意见。

• 不要过度地追求完美，不要陷入过度单纯化的诱惑。一般而言，一个好的主意是在你已经有了一个可以用来测试的模型并且已经开始测试的情况下产生的，然后在收集结果的时候再逐渐增强它。

如何为web应用建立负载模型

J. D. Meier, Prashant Bansode, Carlos Farre, Scott Barber编写 秀霞翻译

 

应用于：

Web 应用

性能测试

 

摘要

这里要描述如何创建负载模型，这个负载模型可以表示预计web应用如何在实际环境中工作。对于性能测试的结果可以理解为真实环境下的性能特性，测试用的负载模型必须代表真实用户场景。创建一个合理准确的现实表述，你必须理解使用应用的业务前后逻辑关系，不同情况下所期望的事务，期望的用户路径，以及其他可以利用的要素。

目录

目标

概要

步骤的摘要

步骤1：识别目标

步骤2：识别关键场景

步骤3：为关键场景确定导航路径

步骤4：为导航路径或模拟用户识别唯一的数据

步骤5：确定场景的相对分配

步骤6：识别负载水平的目标

步骤7：准备执行模型

 

目的

学习如何根据期望、文档、观察分析以及以前版本可以得到的数据为web应用组建和实现负载模型。

概述

负载模型是一个识别一个或者多个混合的应用使用情况的过程，一般用在性能测试中。一个负载模型包括和数据相关的项，诸如：

• 关键用户的行为；

• 导航路径的相关的行为；

• 相关的用户分布以及（或者）跨目标负载的行为；

• 唯一的数据和模拟的每个用户中应用相互影响。

然而，模拟不切实际的负载模型可以在执行性能测试的时候为团队提供有价值的信息，这当然是正确的，你可以仅仅加一些准确的前提条件，就可以让现实情况被模拟，并为产品进行性能测试或者实现性能优化。

步骤的总结

步骤的摘要

步骤1：识别目标

步骤2：识别关键场景

步骤3：为关键场景确定导航路径

步骤4：为导航路径或模拟用户识别唯一的数据

步骤5：确定场景的相对分配

步骤6：识别负载水平的目标

步骤7：准备执行模型

最近在整理负责产品的负载模型，见得这个文章还不错，先转过来。

------

一个访问量达到百万级别的门户网站及奥运会订票系统等这中用户数较多的系统，进行性能测试是必须的。要不就和产品演示会上出现的笑话一样，风险投资商提出的问题是这个网站能支持多少用户同时上线，项目经理居然说没有进行这方面的测试。全场哗然。。。。
　　对于性能测试的第一步是怎么去根据业务的实际模型分析出具体的测试场景及性能测试的指标。

　　一、 性能测试业务逻辑理解的一些基本概念

　　1、负载测试和压力测试的区别：负载测试在于确定最终满足系统指标的前提下，系统所能承受的最大负载测试，压力测试的目标则在确定什么条件下系统性能处于失效状态。

　　2、吞吐量（Throughput）：指单位时间内处理的客户段请求数量，直接体现软件系统的性能承载能力。

　　3、并发（Concurrency）：多个同时发生的业务操作。例如100个用户同时点登录21CN邮箱和同时在线人数不一样。比如说21CN通行证用户登录的有1万个可能只有20%的人在看博客，10%的人在看相册，30%的人在查看邮件，10%的人在查看播客，10%的人在看视频点播，10%的人在逛论坛等等

　　但是同时在线人数就是1万，并发用户就是针对每个系统的具体人数。

　　二、几种常见的业务模型设计

　　1、e家广告系统：

　　（1）具体的业务参数要求：

　　系统要达到4000万日均PV，则需要平台可以处理4000并发/秒。根据选中的服务器的性能，处理能力约为2000个HTTP并发/秒或1000个流媒体并发/秒。假设这4000万PV中有图片的PV占3000万，流媒体的PV占1000万，则需要WEB服务器及流媒体服务器各两台。

　　（2）具体的测试设计方法：

　　（a）平台的处理能力与要达到的日均PV的能力的计算关系为：

　　参数说明：

　　X：表示整个系统的日均PV值，单位为：万PV/天

　　m：平台最大有效并发数（即用来服务于广告物料显示的并发数），单位为：并发/秒，每小时是3600秒，即每个小时处理的并发数为3600m并发，即0.36m万并发/小时。

　　y：非高峰时期的平均并发数与平台最大并发数的比例，0<y<1

　　Y：高峰期（平台达到最大并发数的70%，平台负载超过70%以后，将变得不稳定）小时数,0<Y<24,即高峰期并发数为70%*0.36m

　　那么：

　　日均PV＝高峰期并发数＊高峰期小时数＋非高峰期平均并发数＊（24－高峰期小时数）

　　即：

　　X=0.7*0.36mY+y*0.36m*(24-Y)

　　即最后结论：

　　X=(0.252Y+8.64y-0.36yY)*m

　　根据经验值，Y＝3，y=30%时，m/X=0.33。而m是平台最大有效并发数，即用来服务于广告物料显示的并发数，而对于每次广告物料的显示，客户端还有访问其它资源如JS代码等，假设每一次广告物料的访问会有伴随另外2个资源的访问。

　　那么平台支撑的总的并发数与需要达到的日均PV的比大约为0.33*3=1。

上面算的比较乱，我换了一种格式表达如下：

分析项目	公式	值
日登录次数	已知	4000万
每日高峰小时数	假设，经验值	3
非高峰小时数	24-3	21
平台最大并发数	X 需要计算的数（个/秒）	0.36X     万个/小时
高峰时并发数	70% 的最大并发数	0.7* 0.36 X 万个/小时
非高峰的并发数	30% 的最大并发数	0.3 * 0.36X  万个/小时
4000= 高峰并发数*并发小时数+非高峰并发数*非并发小时数         = 0.7*0.36X *3+ 21*0.3 * 0.36X         =0.756 X + 2.268 X         = 3 X X=1333

　　

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

下面的好像不是很正确~~~~

（b）实际测试模型设计中结果：

　　面的并发用户数只需要达到N1=0.33*40000000*0.7/24*0.3*3600=356个

　　对于流媒体服务器并发用户数：N2=10000000*0.7/24*0.3*3600/2=135个

　　对于图片服务器并发用户数：N3=30000000*0.7/24*0.3*3600/2=405个

　　2、集团邮箱：

　　（1）具体的业务参数要求：集团邮箱支持支持2000万用户，对性能有要求的操作有邮箱登录，读信，翻页，发邮件（分别是8秒内，2秒内，2秒内，5秒内）。所有的操作均返回HTTP200的状态代码。其中服务器资源分别是登录5台机器（连接PASSPORT），收发邮件5台（不包括POP收发信），其它邮件处理服务器5台，pop/smtp服务器5台。

　　（2）具体的测试设计方法：具体的设计2000万个用户登录时间大概在会在8点到下午18点前操作，而该类业务模型满足80~20原则，比如80%的业务会在20%的时间内处理。则登录的并发用户数设计成多少好呢？ VUlogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此类推。

　　（3）当然如果业务在要求吞吐量的时候，就要更根据吞吐量来设计性能瓶颈所需要的并发用户数这在我们21CN网站和电子商务网站中经常出现。这里引进一个公式VU=F /R*T(VU并发虚拟用户数,F吞吐量,T性能测试时间,R每个VU的请求数量)举例说明（某网站的吞吐量为90亿KB，每个用户每秒50万kb，运行时间30分钟设计出来的每秒用户数VU=9000000000/(500000*30*30)）

　　（4）如办公系统（业务比较频繁的系统）：每天内的一些典型用户固定可以考虑采用一种更准确的计算并发用户数的的方法。公式引进：C=N*L/T,C1=C+ (C是平均并发用户数，N是login session的数量，L是login session的时长，T是考察的时间长度，C1是最高峰值)（*这里的用户是指明确每天都要使用的系统的大概数量来自需求，而这里的用户都是当做一个典型的用户来分析就是登录后会进行正常的流程操作）如21CNEIP每天有320个典型用户访问，系统平均时间为4小时，在一天内用户使用该系统的时间都在8小时内。得出C=320*4/8,C1=C+3 (5)针对这几种模式做一些归纳无论那种模型都是来源于需求根据需求的实际模型是最真实的也是最有效的性能测试模型，在没有典型用户的前提下选择2-8原则（在测试环境中要考虑到等价这个概念就是测试环境服务器数量没有实际环境哪么多的时候要折算过来），有典型用户的情况下选择最大并发数的计算方法，在要求有吞吐量的情况下用吞吐量的计算方法（但是吞吐量的数据要采用上一次测试或者经验值中没有突破系统瓶颈的部分数据要不结果不准确，其中每秒事物数取的是平均值）

　　三、其它值得注意部分

　　1、设置测试场景中并发用户为每隔一段时间增加X个虚拟用户（预热，RAMP UP设置），与同时加载所有的并发用户的测试结果不同，实际的测试中要根据具体业务情况设计。另外实际的数据库记录数和网络环境等都会影响到测试结果。

　　2、建议在实际的测试过程中能多次测试取平均值。

　　3、性能测试的”拐点论”:产生拐点的情况是性能测试产生某种瓶颈，主要原因是某种资源达到了极限。此时表现为随着压力的增大，系统性能出现急剧下降。

　　4、性能测试的系统能力验证: （a）是系统稳定性的一个基本要求，通常表现为系统在要求的平均并发用户下服务器的CPU平均使用率不高于75%，内存的使用率不高于75%。（b）系统在要求的并发用户数达到峰值情况下服务器的CPU平均使用率不高于95%，内存的使用率不高于90%。（c）系统能在高于实际系统运行压力1倍的情况下，稳定的运行72小时。

　　5、为分清各个不同事物的响应时间请务必在多事物的脚本中添加事物以便区分，请在要用到多个帐户或者多个用户的迭代或者循环操作的时候请务必进行参数化（很多系统都限制了同一帐户在多长时间的操作，或者防止数据冲突）。