应用服务器和数据库服务器性能估算
基准：
1) 依据硬件服务器标准TPC-C标准衡量服务器性能指标TpmC对服务器性能进行估算，其中TpmC指标指的是服务器一分钟处理的交易数，C指的是TPC-C标准。
2) TPC-C官方数据对于p5-595（64路2.3GHz主频POWER5+）评测TpmC为：4,033,378
3) 声明：LoadRunner测试的响应时间不等于服务器交易处理时间，LoadRunner测试的响应时间是指一个事物从客户端发起请求到客户端得到响应的时间。包括：客户请求处理时间+网络处理时间+应用服务器（weblogic）处理时间+数据库服务器处理时间。
以下估算服务器性能基于1）和2）两条基准。
估算一：基于“报表修改报送”单用户处理响应时间估算
1） LoadRunner测量单用户情况下“报表修改报送”业务迭代20次测量响应时间为：25ms；
2） 一般情况下网络延时在1ms以内，在这里我们忽略网络延时；
3） 按照客户端处理、应用服务器处理和数据库服务器处理时间比率为：3：1：1进行估算；
4） 根据业务处理应用服务器在此过程中处理交易数为4：接受客户端请求、转发请求，接收数据库请求，转发客户端。
5） 根据“报表修改报送”业务数据库服务器处理请求数为2：接收Web服务器请求，转发Web服务器
6） 应用服务器性能估算
“报表修改报送”业务处理时间：(25/5)*1=5ms
处理一个交易时间：5ms/4=1.25ms
应用服务器TPS: 1000ms/1.25ms=800
应用服务器TPMC:800*2*2*16*60=3072000
6） 数据库服务器性能估算
“报表修改报送”业务处理时间：(25/5)*1=5ms
处理一个交易时间：5ms/2=2.5ms
应用服务器TPS: 1000ms/2.5ms=400
应用服务器TPMC: 400*2*2*16*60=1536000
上述估算仅供参考，由于测量本身受LoadRunner统计相应时间的精度、被测业务“报表修改上报”业务和估算过程中响应时间比率的影响。
二、基于现有系统业务处理上限的估算
1） 由于性能测试工具本身的极限，针对LoadRunner性能测试工具在国内性能测试市场上销售最大的license数量为10000Vusers（市场销售价格超过千万人民币）
2） 因此我们依据现有10000以内并发用户情况下的测量结果对系统应用服务能力进行估算。
3） 通过测量我们发现系统的响应时间随着用户的增加而成线性增长，由此可以得到一个结论，随着并发用户增加，系统的处理能力必将出现瓶颈。因此我们根据现有数据进行估算。确认系统可能的处理理论上限。现有数据如下：
|
序号 |
并发用户数 |
平均响应时间 |
用户数/平均响应时间 |
LR统计TPS |
|
1 |
800 |
0.523 |
1529.636711 |
81.418 |
|
2 |
1120 |
0.72 |
1542.699725 |
81.583 |
|
3 |
1488 |
0.814 |
1828.009828 |
76.173 |
|
4 |
2240 |
1.155 |
1939.393939 |
80.809 |
|
5 |
3712 |
1.547 |
2399.48287 |
73.803 |
|
6 |
4000 |
1.648 |
2427.184466 |
66.164 |
|
7 |
5000 |
1.9 |
2631.578947 |
58.993 |
|
8 |
6000 |
2.112 |
2840.909091 |
36.786 |
|
9 |
7000 |
2.311 |
3019.844694 |
44.072 |
|
10 |
8000 |
2.587 |
3092.385002 |
38.283 |
|
11 |
9000 |
2.573 |
3496.503497 |
32.326 |
|
12 |
10000 |
2.612 |
3818.251241 |
33.952 |
根据上表中的数据以及响应时间的线性增长，理论情况下，响应时间、吞吐量（tps）和响应时间存在着一定的数学模型。理论图形如下：
吞吐量和负载之间的关系：
1、吞吐量和负载之间的关系可以分为三个阶段，上升阶段、平稳阶段和下降阶段；
2、在上升阶段，吞吐量随负载的增加而增加、吞吐量和负载成正比；
3、在平稳阶段，吞吐量随着负载的增加基本不变；
4、下降阶段，吞吐量随负载的增加而减小，吞吐量和负载成反比关系。
a1的面积越大，说明系统的性能能力越强。a2的面积越大，系统的稳定性越好。a3的面积越大，说明系统的容错能力越好。
因此我们根据并发用户、响应时间和吞吐量的数学关系对系统的性能推算如下：
1、考虑9000并发和10000并发用户测试在下午下班以后进行，网络速度较快，从测试数据分析，性能表现明显优于前几组数据，本次推算不采用9000并发和10000并发的测试数据。
2、计算平均响应时间增量/并发用户增量的平均值
|
并发用户数 |
并发用户增量 |
平均响应时间 |
平均响应时间增量 |
平均响应时间增量/并发用户增量 |
|
800 |
- |
0.523 |
- |
- |
|
1120 |
320 |
0.72 |
0.197 |
0.000615625 |
|
1488 |
368 |
0.814 |
0.094 |
0.000255435 |
|
2240 |
752 |
1.155 |
0.341 |
0.000453457 |
|
3712 |
1472 |
1.547 |
0.392 |
0.000266304 |
|
4000 |
288 |
1.648 |
0.101 |
0.000350694 |
|
5000 |
1000 |
1.9 |
0.252 |
0.000252 |
|
6000 |
1000 |
2.112 |
0.212 |
0.000212 |
|
7000 |
1000 |
2.311 |
0.199 |
0.000199 |
|
8000 |
1000 |
2.587 |
0.276 |
0.000276 |
|
均值 |
0.000320057335743082 |
平均响应时间增量/并发用户增量的平均值约为0.00032
3、根据行业标准的“2-5-8原则”，当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
（5-2.587）/0.00032=7540.625,约为7541；
8000+7541=15541
（8-2.587）/0.00032=16915.625，约为16916；
8000+16916=24916
（120-2.587）/0.00032=366915.6,约为366916；
8000+366916=374916
因此：
小于5000用户并发操作修改业务时，用户感觉系统的响应很快；
小于15541用户并发操作修改业务时，用户感觉系统的响应还可以；
小于24916用户并发操作修改业务时，用户感觉系统的响应可以接受；
大于24916用户并发操作修改业务时，用户感觉系统的响应不可接受；
374916用户并发操作修改业务时，系统响应时间超过120s。