L1 cache reference 0.5 ns (4096KB) (cpu内1级缓存)
L2 cache reference 7 ns(16MB)      (cpu内2级缓存)
Branch mispredict 5 ns  (内存计算时，分支预测失败)
Mutex lock/unlock 100 ns     (加解锁)
Main memory reference 100 ns (一次访存开销)
Compress 1K bytes with Zippy 10,000 ns
Send 2K Bytes over 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns (磁盘IO寻道时间10ms)
Read 1 MB sequentially from network 10,000,000 ns (10ms 1mb from 网络，网络带宽约100MB/s)
Read 1 MB sequentially from disk 30,000,000 ns (30ms 1mb from 磁盘，磁盘带宽约30MB/s)
Send packet CA->Netherlands->CA 150,000,000 ns (150ms 网路包发生确认)

性能估算(修改版)  http://blog.csdn.net/ajian005/article/details/7680007

1. 本转载文章对设计者在性能估算上非常有参考价值；

2. 负责技术运营、运维的同学前期早参与开发设计是非常有必要的，特别是一些经验丰富的同学在线上大流量下见多识广，对一些性能、瓶颈值比较熟悉；

3. 开发的系统适合运营生产环境是一个上线的准入条件，否则运营成本巨大，即使上线了也是问题服务，不如在上线前就把关解决掉。

给定一个问题，往往会有多种设计方案，而方案评估的一个重要指标就是性能，如何在系统设计时估算而不是在程序执行时测试得到性能数据是系统架构设计的重要技能。

性能估算有如下用途：

1)  多种设计方案选择；
2)  评价程序实现是否足够优化；
3)  向框架/服务提供方提出性能要求的依据；
通过查看程序运行时CPU及网络的使用情况来评价程序是否足够优化，这也是一种很重要的方法。然而，这种方法掩盖了不优化的实现，如O(N)的算法被错误实现成O(N^2)，网络收发冗余数据等。
性能评估需要假设程序的执行环境，如集群规模及机器配置，集群上其它服务占用资源的比例。首先，我们需要知道一些常见硬件的大致性能参数：
L1 cache reference                     0.5ns
Branch mispredict                      5ns
L2 cache reference                     7ns
Mutex lock/unlock                      100ns
Main memory reference                  100ns
Send 1M bytes over 1Gbps network       10ms
Read 1M sequentially from memory       0.25ms
Round trip within data center          0.5ms
Disk seek                              8~10ms
Read 1MB sequentially from disk        20~25ms
标记为红色性能参数比较常用，其中，磁盘的性能指标专指分布式平台专用的大容量磁盘，寻道时间为8~10ms，顺序读取速率为40~50MB。某些产品线 使用SCSI磁盘或者Flash盘，性能较好，评估时需查看硬件的性能参数。磁盘和网络都有一个特征，一次读写的数据量越大性能越好，这是由硬件特征及底 层软件算法决定的，如tcp慢连接和磁盘寻道时间长。

对硬件性能指标有了初步认识以后，我们可以做出一些简单的判断，如：

 

某后台开发同学：某检索程序A单客户端同步读取每秒可以达到18000/s。
问：是否批量读取？
答：是，每批读取10个记录。

  由于tcp Round trip时间为0.5ms，读取请求个数的理论极限为2000/s，而A的开发同学却说单客户同步读取可以达到18000/s，可以断定A开发同学指的是批量读取方式。且这已经是单机能够做到的极限值了。

 

下面我们通过几个实例说明如何进行性能评估。
1. 1GB的4字节整数，内存排序时间为多少？

拿到这个问题，假设用快速排序，快速排序的时间复杂度 T = O(N*log(N)),我们往往会计算CPU运算次数，如快排的运算次数为1.4 * N * log(N)，其中1.4为快排的系数，再根据CPU的运算频率计算出排序耗时。不过这种方法很土也不是很准，Jeff Dean告诉我们可以这样估算：排序时间 = 比较时间（分支预测错误） + 内存访问时间。快排过程中会发生大量的分支预测错误，所以比较次数为2^28 * log (2^28) ≈ 2^33，其中约1/2的比较会发生分支预测错误，所以比较时间为1/2 * 2 ^ 32 * 5ns = 21s(这个结果是有疑问：用计算机计算过程2^32=4294967296,  1/2 * 2^32=2147483648,  1/2 * 2^32 * (5/1000000000)s = 10.73741824s)，另外，快排每次找到分割点都需要一遍内存移动操作，而内存顺序访问性能为4GB/s，所以内存访问时间为28 * 1GB / 4GB = 7s（疑问28 * 1GB是如何出来的？）。因此，单线程排序1GB 4字节整数总时间约为28s（10.73741824s(比较时间分支预测错误) + 7s(内存访问时间) =17.73741824s）。

扩展问题:

1.1  1GB的4字节整数，内存查找时间为多少？

    假设已经排好序的数据，考虑二分查找，二分查找的时间复杂度 T = O( logN ),

    首先 求出N = 1GB/4 = 2^30/2^2 = 2^28 = 268435456个4字节整数≈2亿6千8百万个整数。

    其次 二分查找时间复杂度 T = O( logN ) = O(log268435456) = 8.4288398785914734659846890522858(次) ≈ 9次

     最后 假设二分查找时间= 比较时间(分支预测错误)  + 内存访问时间

     比较时间(分支预测错误) = 1/2 * 9次 * 5ns = 22.5ns

     内存访问时间 = ???

1.2 1GB的4字节整数，内存排序空间为多少？

    快速排序S = O(logn)

1.3 1GB的4字节整数，内存查找空间为多少？

     二分查找S = O()

2. DTS设计的性能指标分析
DTS总体设计中给出的性能指标为:
系统配置：50台4核8GB内存12路SATA硬盘，同样数量的客户端；
Table：row name：16-byte，column：16-byte，value：1KB；64KB data block；no compression；
Random reads (in disk)： 1KB/item*300item/s*50=15MB/s
Random reads (in memory)：1KB/item*4000item/s*50=200MB/s
Random writes：1KB/item*2000item/s*50=100MB/s
Sequential reads(in disk)：1KB/item*1000item/s*50=50MB/s
Sequential writes：1KB/item*2000item/s*50=100MB/s
先看磁盘中的随机读取性能，由于在DTS的设计中每个随机读写都要读取一个64KB的大块，而磁盘中读取64KB数据时间为：磁盘寻道时间 + 读取时间 = 8ms + 64KB / 50MB/s = 20ms。所以每秒读取300个记录要么是批量读取，要么是异步读取。由于每台机器有12个SATA大容量磁盘，随机读的理论值为12 * 50 = 600个/s。设计为每秒读取300个是考虑到有负载平衡等因素简单地打了个对折。
再看内存中的随机读取。一般来说，内存操作都是每秒1W~10W。由于网络发送小数据有较多overhead且DTS内存操作有较多的内存开销，所以保守设计为单机每秒读取4000个记录。

其它的可类似分析。性能分析可能会很复杂，因为不同的情况下决定性能的瓶颈不一样，有的时候是网络，有的时候是磁盘，有的时候甚至是机房的交换机。这种性能分析的经验是需要慢慢积累的。

最后，我们再看看一个例子。该程序R是一个MapReduce应用，MapReduce可以简单地分为几个过程：Map处理时间 + shuffle和排序时间 + reduce处理时间，虽然shuffle、map处理和排序可以部分并行，但性能估算的时候不必考虑。假设50台机器，原始输入为50G，30个策略时 R应用的map处理时间为100s，R应用的reduce处理时间为60s，shuffle的中间结果数据量为300G，reduce输出的最终结果大小 为600M。

Map处理时间= 输入读取时间+ Map处理时间 + 输出中间结果时间
其中，输入读取时间 = 50G / 2.5G = 25s (50台机器，假设每台机器读取带宽为50M/s)，
R应用的map处理时间 = 60s，
输出中间结果时间 = 300G / 15G = 20s (50台机器，每台机器12个磁盘，假设用满6个磁盘，带宽为6 * 50M = 300M)
所以，Map处理时间 = 25s + 60s + 20s = 105s
Shuffle和排序时间 = shuffle时间+ 排序时间
其中，shuffle时间 = 300G / 2G = 150s (50台机器，假设每台机器的读取和写入带宽均为40M，单机总带宽为80M)
排序时间 = 单机排序6G的时间，假设每条记录为1KB = 排序比较时间 + 访问时间，约为25s
所以，shuffle和排序的时间 = 150s + 25s = 175s
Reduce处理时间 = R应用的reduce处理时间 + 最终结果输出时间
其中，R应用的reduce处理时间 = 100s，
最终结果输出时间 = 600M / 500M (50台机器，单机写DFS假设时间为10M/s) = 1s (忽略)
所以，R一遍MapReduce的估算时间 = Map处理时间 + shuffle和排序时间+ Reduce处理时间 = 105s + 175s + 100s = 380s，当然，MapReduce过程中还有框架的开销和其它应用的影响，我们可以简单地认为影响为20%，所以总时间 = 380s + 380s * 20% = 456s，约为7~8 min。
当然，R实际的性能估算不会如此简单，实际估算时需要考虑每台机器上启动的Map和Reduce个数等因素，且需要根据实验的结果不断地验证和重新调整估 算。但是，我们至少可以保证，估算的结果和实际不会相差一个数量级，估算结果可以用来指导初期的设计和Map/Reduce Worker的个数、Map/Reduce任务数选择，评估应用的可优化空间并作为向MapReduce框架提供小组提出需求的依据。
性能估算是大规模系统设计中较难掌握的技能，开始性能估算时可能估计得很不准，不过不要气馁，通过在项目中不断练习，大规模系统的分析和设计能力可以提升一个档次。
*************************************

应用系统性能估算 http://blog.csdn.net/test_sunny/article/details/6070231

 

应用服务器和数据库服务器性能估算

基准：

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） 通过测量我们发现系统的响应时间随着用户的增加而成线性增长，由此可以得到一个结论，随着并发用户增加，系统的处理能力必将出现瓶颈。因此我们根据现有数据进行估算。确认系统可能的处理理论上限。现有数据如下：

根据上表中的数据以及响应时间的线性增长，理论情况下，响应时间、吞吐量（tps）和响应时间存在着一定的数学模型。理论图形如下：

 

吞吐量和负载之间的关系：

1、吞吐量和负载之间的关系可以分为三个阶段，上升阶段、平稳阶段和下降阶段；

2、在上升阶段，吞吐量随负载的增加而增加、吞吐量和负载成正比；

3、在平稳阶段，吞吐量随着负载的增加基本不变；

4、下降阶段，吞吐量随负载的增加而减小，吞吐量和负载成反比关系。

a1的面积越大，说明系统的性能能力越强。a2的面积越大，系统的稳定性越好。a3的面积越大，说明系统的容错能力越好。

 

因此我们根据并发用户、响应时间和吞吐量的数学关系对系统的性能推算如下：

1、考虑9000并发和10000并发用户测试在下午下班以后进行，网络速度较快，从测试数据分析，性能表现明显优于前几组数据，本次推算不采用9000并发和10000并发的测试数据。

2、计算平均响应时间增量/并发用户增量的平均值

平均响应时间增量/并发用户增量的平均值约为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。

 

*******************************************************

服务器处理性能估算 http://murray.cn/index.php/2008/10/tpcc-web-server/

Posted by murray

10月 13, 2008

系统的建设，必须满足未来5年业务发展和管理的需求，所以下面对服务器性能指标的估算，将以满足未来5年的需要为基准。
1. 数据库服务器
1.1. TPCC值估算
约定：
系统同时在线用户数为100人（U1）；
平均每个用户每分钟发出2次业务请求（N1）；
系统发出的业务请求中，更新、查询、统计各占1/3；
平均每次更新业务产生3个事务（T1）；
平均每次查询业务产生8个事务（T2）；
平均每次统计业务产生13个事务（T3）；
一天内忙时的处理量为平均值的5倍；
经验系数为1.6；(实际工程经验)
考虑服务器保留30％的冗余；
服务器需要的处理能力为：
TPC-C=U1*N1*（T1+T2+T3）/3*3*经验系数/冗余系数
则数据库服务器的处理性能估算为：
TPC-C= 100*2*（3+8+13）/3*5*1.6/0.7= 18,285 TPM

1.2. 内存估算
该服务器内存主要由操作系统占用内存、数据库系统占用内存、并发连接占用内存等几部分组成。
约定：
操作系统占用约400M内存空间；
数据库系统占用内存0.8G ；
每个并发连接占用5 M；
考虑服务器内存保留15％的冗余；
则服务器的内存估算为：
Mem =(400M + 0.8GB??+ 100*5M) /(1-15%)??= 2 GB
1.3. 存储容量估算
预算管理系统中存储着预算编制数据等资料信息以及日志等管理信息。
在已经考虑了数据冗余的前提下，约定：
每月有100个分局或部室编制预算；
每月每个分局或部室编制1次预算；
预算模板共含6000个预算指标；
每个预算指标含5条明细项目；
每条记录占用空间300B；

每月的预算数据存储容量需求：6000*5*100*500B=1.5G
每月的日志数据存储容量需求：0.1G
每月进行数据备份一次，数据存储容量需求：12*9G=108G
整年总共需用存储容量：12*1.5G+1.5G+12*0.1G+12*9G=20.7G+108G=128.7G

约定系统中预算编制数据等资料信息以及日志等管理信息在线保存5年(备份数据每年进行清除)，则预算管理系统的存储容量估算为：
5*20.7G+108G =103.5G+108G=211.5G
1.4. 服务器安装软件
该服务器中将需要安装的软件如下：
操作系统为：Windows 2000 Server
数据库：Oracle
1.5. 建议配置
根据以上的性能指标建议数据库服务器标准配置如下：
应用名称 功能描述 数量 说明
数据库服务器 CPU: TPCC值应大于18,285 TPM
内存：2G及以上
硬盘：211.5GB以上（建议通过RAID5或镜像等方式进行数据备份）
以太网卡：100M及以上 1

1.2. 中间件应用服务器
1.2.1. TPCC值估算
约定：
系统同时在线用户数为100人（U1）；
平均每个用户每分钟发出2次业务请求（N1）；
系统发出的业务请求中，更新、查询、统计各占1/3；
平均每次更新业务产生3个事务（T1）；
平均每次查询业务产生8个事务（T2）；
平均每次统计业务产生13个事务（T3）；
一天内忙时的处理量为平均值的5倍；
经验系数为1.6；(实际工程经验)
考虑服务器保留30％的冗余；

服务器需要的处理能力为：
TPC-C=U1*N1*（T1+T2+T3）/3*3*经验系数/冗余系数

则数据库服务器的处理性能估算为：
TPC-C= 100*2*（3+8+13）/3*5*1.6/0.7= 18,285 TPM

1.2.2. 内存估算
该服务器内存主要由操作系统占用内存、数据库系统占用内存、并发连接占用内存等几部分组成。
约定：
操作系统占用约400M内存空间；
中间件用户服务器占用内存0.8G ；
每个并发连接占用5 M；
考虑服务器内存保留15％的冗余；
则服务器的内存估算为：
Mem =(400M + 0.8GB??+ 100*5M) /(1-15%)??= 2 GB
1.2.3. 存储容量估算
主要系统中间件应用服务器和操作系统本身至少5G以上。
其中操作系统约占2G，应用服务器约占3G。
1.1.2.4. 服务器安装软件
该服务器中将需要安装的软件如下：
操作系统为：Windows 2000 Server
中间件应用服务器：系统中间件应用服务器
1.1.2.5. 建议配置
根据以上的性能指标建议服务器标准配置如下：
应用名称 功能描述 数量 说明
应用服务器 CPU: TPCC值应大于18,285 TPM
内存：2G及以上(建议3G以上)
硬盘：5GB以上
以太网卡： 100M及以上 1台

数据库服务器性能TPC-C测算

每秒峰值：6,000个连接/秒，即主机处理峰值应能达到6,000连接/秒；
每个连接平均需要10个数据库访问，按照经验，每个数据库访问相当于服务器3-4tpm的处理能力。

峰值连接： 6,000连接/秒
每个连接： 10个数据库访问
每个访问： 3—4 tpm (transaction per minute)
则应用要求服务器的TPC-C为：
6000 x 10 x 4 = 240,000tpm
系统本身要消耗30%的系统资源，则应用与系统要求服务器的TPC-C为：
240,000tpm / 70% = 342,857tpm
而服务器的实际资源占用即“系统忙”不应大于70%，则实际要求数据库服务器的处理性能TPC-C为：
342,857tpm / 70% = 489,796tpm。
因此，数据库双机系统TPC-C要求大于或等于500，000tpm，考虑实现Oracle 9i RAC后，双机性能是单机的确1.8倍，因此单机TPC-C不能小于
500,000/1.8=278,000tpm。

应用服务器性能TPC-C测算

每秒峰值：10,000个连接/秒，即主机处理峰值应能达到10,000连接/秒；
应用服务器的连接，相当于5—6个数据库访问，按照经验，每个数据库访问相当于服务器3-4tpm的处理能力。

峰值连接： 10,000连接/秒
每个连接： 5—6个数据库访问
每个访问： 3—4 tpm (transaction per minute)
则应用要求服务器的TPC-C为：
10000 x 6 x 4 = 240,000tpm
系统本身要消耗30%的系统资源，则应用与系统要求服务器的TPC-C为：
240,000tpm / 70% = 342,857tpm
而服务器的实际资源占用即“系统忙”不应大于70%，则实际要求服务器的处理性能TPC-C为：
342,857tpm / 70% = 489,796tpm。

Web服务器性能测算

Web服务器：建议采用中低档UNIX服务器，可以采用多台低档UNIX服务器并行，实现均衡负载、抵御不友好访问。
SPECweb99是衡量Web服务器处理能力的主要指标，是服务器可以承受的同时“点击”的次数，数值越高处理能力越强。
WEB SERVER集群所支持的并发访问量不少于5万，如果响应时间在1-2秒，则要求SPECweb99为：50,000/1.5 = 33,333

服务器处理能力，你估算正确过吗？

http://blog.csdn.net/cxxsoft/article/details/7489116

服务器处理能力，你估算正确过吗？

作者：成晓旭

 

1    【引题】

   但凡写过技术方案的都知道，在技术方案最终落实到工程实施部署时，必须编制出当前解决方案需要部署的IT设备及环境，包括：需要的网络环境、端口、带宽、 组网方式、网络安全保障措施；需配置的服务器设备性能、数量；需配置的存储数据存储设备、容量、存储速率；甚至还需考虑整个系统的备份设备容量、备份 I/O数、速率、备份策略等。

   严格说来，无论是系统厂商、集成公司、还是研究院、设计公司，在最终提供方案的硬件配置时，都应该以业务需求为依据、适当考虑客户业务的发展趋势和系统冗 余，详细估算：当前业务需求对网络带宽、对处理能力、对数据存储容量的指标。因此，本文以自己的项目案例和经验为基础，简述计算机处理能力如何正确估算， 供大家参考。

2    【性能评测标准】

   众所周知，事务处理性能委员会的TPC-C标准，是测算和衡量计算机硬件设备性能的行业标准。随着B/S技术架构的大行其道，SPEC组织专门推出了针对 Web服务器响应客户端Web访问请求的性能测算标准，即SPEC web系列。因此，如果是传统的基于事务处理模式的服务器，仍采用TPC-C的方式进行测算；如果是Web服务器，则需要采用SPEC web系列的标准进行测算。然而，很遗憾的看到，很多人在测算服务器性能时完全忽视这两种差别。

1.1  TPC-C标准

   TPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能（OLTP）的性能基准，它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能，这些事务进程于一个可控制的状态下在一个标准的数据库中运行。

   TPC-C的事务处理是在一个9个表的数据库上实现的事务处理过程包括：更新、插入、删除、终止，以及对主和次级键的访问，每种事务处理95%的响应时间 应小于或等于5秒，其中，库存水平的响应时间可以在60秒以内。TPC-C值表示每分钟处理的标准事务量，单位是tpmC。

1.2  SPEC web标准

   SPEC web99，WEB 服务器可以支持的并发接入数。SPECweb99 检测程序模拟客户通过慢Internet连接，向Web 服务器发送HTTP 工作量请求。

   SPEC Web2005，作为SPECweb99的继承者，SPECweb2005延续了SPEC的传统测试的原理，通过多台客户机向服务器发出Http Get请求，请求调用Web服务器上的网页文件，这些文件从数千字节到数兆字节不等。在相同的时间里，服务器回答的请求越多，就表明服务器对客户端的处理 能力越强，系统的Web性能就越好。

3    【性能估算公式】

3.1  常见的错误估算方法

   在技术方案评审和招投标评标过程中，我常常看到这样的评估服务器处理能力的表格：

   示例一：

   示例二：

   不知道这种评估方法是从那里开始的，在技术方案文档中，曾多次看到这样的评估模型和表格。即不全是TPC-C的评估方法，又不全是SPEC Web体系的评估方法。

3.2  TPC-C估算公式

   TPC-C是用计算机设备在每分钟内所能处理的标准事务的数量来衡量其处理能力的多少；因此，估算一个应用场景对处理能力的需求，本质上就是估算出每类业 务处理事务对应的标准tpc-c事务量，然后在适当考虑冗余量。TPC-C的测算结果是每分钟的事务数，单位是tpmc。

   TPC-C的通用估算公式如下：

   TPC-C = ∑(每分钟业务事务量 * 标准事务量比率)/ (1 — 冗余率)。

   例如：某业务系统有2类业务处理事务操作，业务事务1每分钟30000个，每个业务事务1操作相当于0.5个标准tpc-c事务；务事务2每分钟20000个，每个业务事务2操作相当于2个标准tpc-c事务；考虑30%的系统冗余。则该业务应用需要的处理能力为：

   服务器处理能力(tpmc) = ((30000 X0.5) + (20000 X 2)) / (1 – 30%) = 78581。

3.3  SPEC Web估算公式

   SPEC Web2005标准的衡量结果是一台Web服务器能够有效响应客户端的Web请求的最大极限个数。因此，测算的结果应该是一个Web请求数字，单位是个。

   在评估应用服务器的SPEC Web2005值时，通常的方法是通过系统的在线用户，结合其在线率估算出并发用户数，在参照日常业务使用场景中可能发起的http请求来进行估算。

   SPEC Web2005的参考估算公式如下：(注意：公式仅供参考，需根据项目的具体情况自行设计估算模型)

   Web访问响应能力(SPEC Web2005) = (在线用户数* 在线率* 在线用户平均发起http请求数)/ (1 — 冗余率)。

   例如：某业务系统的在线用户数为2000，在线率10%，每在线用户平均发起的http请求数为3，考虑30%的系统响应能力冗余。则负责该业务请求的Web服务器的响应能力为：

   Web访问响应能力(个) = 2000 * 10% * 3 / (1 – 30%) = 857。

4    【应用实例】

   下面以一个实际工程项目的应用服务器(部署Web Service中间件)的性能估算为例进行示范。

   应用服务器上运行中间件产品，承担系统的各类业务逻辑组件运行计算，收敛系统用户对数据库服务器的访问请求，集中对外提供应用服务。通过分析，应用服务器性能需求在于：提供Web应用服务、业务逻辑处理。

   Web应用服务方面，根据的业务预测数据，应用服务器平均在线并发用户按200估算，并发在线率20%，每用户平均发起3个http链接，考虑30%系统 响应冗余能力，参照SPECweb99的评测标准，Web应用服务性能需求：Web服务器最大并发连接数=(120×20%×3)/(1 - 30%)= 103。

   业务逻辑处理性能方面，主要的应用服务组件性能需求在于：集团数据监测分析、省数据监测分析、业务数据查询。据调研统计，集团数据为每分钟3585 条，省数据平均为每分钟51667条，业务信息查询请求平均为每分钟2151次；集团数据监测分析，每次业务操作约需3个标准tpcc事务，省数据监测分 析，每次业务操作约需2个tpcc事务，业务信息查询，每次业务操作约需2个tpcc事务；则系统主机的处理能力需求TPCC值计算如下：

因此，应用服务器的处理能力配置不能低于196731tpmc，其Web2005配置指标不能低于103个。

5    【经验总结】

   针对事务处理型应用场景，需要采用TPC-C的估算方法，估算出具体需要的总tpmc值；而针对Web客户端请求响应型应用场景，除了估算其业务处理能力之外，还需要评估其对客户端Web请求的响应能力，实际配置的服务器一般不能低于估算结果。

   除了考虑存业务处理需要的处理能力需求外，还需要考虑设备运行环境上其他基础服务运行开销：例如操作系统、数据库服务器、Web服务器、应用中间件等。

   由于当期硬件设备发展非常迅速，一般标配的PC服务器的tpcc值也常常是几十万，高配的甚至上百万。因此，还有两条经验提醒大家注意：

  其一，如果业务需求的tpcc值测算出来其实很低(绝大部分应用都是如此)，配置一台很低端的PC服务器都能够满足处理能力需求，不能因为想给客户提供高配置的设备，而胡乱的编纂tpcc值；而应该从其他方面寻找更加充分有力的理由。

  其二、由于PC服务器处理能力的增强，tpcc值往往不再成为必须选择小型机的一个比较充分的理由；但需要给客户报配小型机方案时，可以尝试从稳定性、可靠性、高I/O需求、设备同构需求、外围设备特殊要求等方面多想办法，而不能再一味只从tpcc值这个角度去考虑。

*******************

数据库服务器硬件性能估算示例及问题 http://itbbs.pconline.com.cn/network/10898634.html

参照搜集的相关资料, 在项目中对数据库服务器硬件的进行性能估算。因为对硬件选型不是很在行，感觉问题不少。

1.TPCC值估算

在性能估算中，我们对系统上线后的运行状况做以下假定：

l 系统同时在线用户数为250人（U1）；

l 平均每个用户每分钟发出4次访问请求（N1）；

l 系统发出的业务请求中，查询、统计各占2/5，更新占1/5，其中：

a.平均每次查询业务产生8个事务（T1）；

b.平均每次统计业务产生13个事务（T2）；

c.平均每次更新业务产生3个事务（T3）；

l 日内处理繁忙时的处理量为平均值的3倍；

l 根据多个项目的实际工程经验，应采取经验系数1.6；

l 考虑服务器保留30％的冗余；

根据假定及运算公式，所需的数据库服务器的处理性能估算为：

TPC-C= 250*3*(8*2+13*2+3)/5*4*1.6*(1+0.3)= 56,160 TPM

2. 内存估算

数据库系统服务器的内存使用过程中，主要由操作系统占用内存、数据库系统占用内存、并发连接占用内存等几部分组成。

项目中，我们根据经验作如下假定：

l 操作系统占用约0.5G的内存空间；

l 数据库管理系统占用约1G的内存空间；

l 每个并发连接占用5M的内存空间；

l 考虑服务器内存保留30％的冗余；

根据以上假定，数据库服务器的内存估算为：

Mem = (0.5+ 1 + 250*0.005) *(1+30%) = 3.6 GB

3. 存储估算

待整理。

4. 问题

l TPC-C和现有硬件所宣称的指标差距太大，宣称的能力是估算的10倍

|实际中带宽往往是瓶颈，但不同应用类型带宽估计差异很大

|Session/Process/Mem-Disk Load&unload在实际中的代价无法这样估算出来