性能测试的几种业务模型设计

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

------

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

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

　　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。

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

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

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