性能测试容量计算方法

　　关于性能测试，你可能会比较关心将系统从超负荷运行中解救出来所需要的时间。

　　我们先来介绍几种性能测试的类型。

　　容量测试主要关心的是我们在系统容量达到什么程度的时候需要增加系统的资源以增加可支持用户量(注：也就是确定系统可处理同时在线的最大用户数)

　　负载测试为IT系统提供了一种量化其在真实环境下承受能力的的方法，便于检验当前所提供的IT资源能否承受预期给出的性能指标。(注：测试数据在超负荷环境下运行，程序能否承担)

　　压力测试则关心的是一个系统所能承受的最大的负载情况。(~我还是没看大懂他们之间很明显的区别……)

　　系统的可承受负载一般认为是当用户发现反应时间变慢的时候的负载值，这个值一般需要通过性能测试来获得。

　　当前负载(当前实际需求)和负载测试中得到的负载数据的差值就是系统给用户预留的负载储备--即“峰值储备”，以应对客户负载增加及处理用户负载变化等

　　负载平衡管理器的主要任务就是处理那些空闲的线程占用资源的等问题，以避免因系统资源不足导致严重后果。

　　如果我们有一个比较好的计划并且有过试验经验的话(这需要有一个时间表来计划这一系列活动)，升级系统将变得比较顺利。

　　我们可以这样估计系统资源什么时候被耗尽：分析当前系统可用资源量以及系统资源被蚕食的速率(一般我们是以天为单位来计算的)，我们还要跟踪系统资源变化(以天为单位)以估计我们什么时候应该开始增加系统资源的工作。

　　跟踪系统的反应时间(接收请求到发出响应的总时间)，当这个时间达到某个值的时候我们也需要进行相应的处理或者增加系统资源

　　下面这张表给出的是一个需要进行这种处理的例子，我们将对它进行一个分析

　　计算方法示例

　　1 一项对以前文档的分析结果显示，某系统目前每小时处理300 000页面元素请求，如果按照每个页面平均10个页面元素来算的话，就是系统每小时处理30 000个页面

　　2另外一项分析表明每个用户处理事务平均为三个页面，也就是说现在我们每小时需要处理10 000个用户事务请求

　　3 市场部的调研指出一年之后我们的用户负载将要增加一倍，也就是说我们在那个时候每小时需要处理600 000个页面元素的请求，或者说60 000个页面请求，也就是20 000个用户事务处理

　　这样算来，负载的增加量就是60 000页面请求-30 000页面请求(现在)=30 000个页面请求每小时平均每天的负载增加率就是100%/365=2.74%， 每天需要多处理30 000*2.74%=82.2个页面请求(假设用户的负载增长是线性的)。

　　4 当前的负载测试运行结果表明，我们的系统每小时最多处理60 000个页面请求，如果页面请求数超过这一数值的话就会导致系统出现问题，另一方面，当页面请求达到50 000个每小时的时候，反应时间就会开始降低。

　　为得到可用系统资源数据，我们需要做一个减法，50 000-30 000=20 000个页面每小时，也就是说现在系统的资源还可以支持20 000个页面请求(每小时)

　　用这个数据除以82.2我们知道我们的系统还可以保证(20 000/82.2=)243天在正常的负载条件下运行

　　5 另外一个碰头会议告诉我们大概需要40天的时间用于安排，升级设备，安装，部署，测试等等一系列的活动之后才可以成功升级我们的系统，这还是在一切顺利的时候，如果算上缓冲时间，我们就需要在再加上十天的时间。(注：指作者进行的项目)

　　这也就是说我们至少需要在系统达到资源支持极限状态五十天前开始对我们的系统进行升级。

　　如果我们的估计足够准确的话，我们就需要在(243-50=)193天之后开始进行系统的升级。

　　在进行系统升级的过程中(50天时间里)，预期的工作负载增长超过50天*82.2每天=4110个页面请求每小时

　　这样向前推断的话，我们开始处理工作负载问题的时间就是当工作负载达到50 000-4110=45890个页面请求每小时的时候

原文转自：http://www.uml.org.cn/Test/200812257.asp