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

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应用服务方面，根据的业务预测数据，应用服务器平均在线并发用户按120估算，并发在线率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://blog.csdn.net/cxxsoft/article/details/7489116