参考文档系统能力需求估算

数据库效劳器实现核心数据的存储和处置。数据库效劳要求长期稳固的运行，效劳器硬件要保证长时刻无端障运行，系统必需提供硬件的冗余性能。

本平台的效劳器硬件不但会依照知足当前需求进行配置，而且要考虑预留必然的系统扩展能力。

总性能需求=业务处置性能+接口处置性能+报表统计分析。

1.1.1.1 业务处置性能需求

数据库效劳器需要的处置性能估算为：

系统同时在线用户数为50人（U1）；平均每一个用户每分钟发出2次业务请求（N1）；

系统发出的业务请求中，更新、查询、统计比例为 3:6:1； 平均每次更新业务产生30个事务（T1）； 平均每次查询业务产生70个事务（T2）； 平均每次统计业务产生90个事务（T3）；

一天内忙时的处置量为平均值的5倍；体会系数为1.6；(实际工程体会);考虑效劳器保留30％的冗余；

效劳器需要的处置能力为：

TPC-C=U1*N1*(（T1+T2+T3）/3)*5*体会系数/冗余系数 那么处置性能估算为：

TPC-C=50*2*(30*3+70*6+90*1)/10*5*1.6/0.7= 100*60*5*1.6/0.7=68571.42tpmC=70,000tpmC

1.1.1.2 接口处置性能需求

1.1.1.2.1 基础数据接口

3个系统，PMO，财辅，SAP ,用户数3*10=30(U1),平均每一个用户每分钟发出 5/1440 次业务请求（N1）；系统发出的业务请求中，更新、查询、统计比例为 8:2:0；

平均每次更新业务产生15个事务（T1）； 平均每次查询业务产生30个事务（T2）； (无)平均每次统计业务产生90个事务（T3）；

一天内忙时的处置量为平均值的5倍；体会系数为1.6；(实际工程体会);考虑效劳器保留30％的冗余；

效劳器需要的处置能力为：

TPC-C=U1*N1*（T1+T2+T3）/3*5*体会系数/冗余系数 那么处置性能估算为：

TPC-C=30*(5/1440)*(15*8+30*2+90*0)/10*5*1.6/0.7= 150/1440*18*5*1.6/0.7=21.42tpmC=22tpmC 1.1.1.2.2 业务数据接口

8个接口，用户数8*2=16(U1)

平均每一个用户每分钟发出 3 次业务请求（N1）； 系统发出的业务请求中，更新、查询、统计比例为 4:5:1； 平均每次更新业务产生20个事务（T1）； 平均每次查询业务产生50个事务（T2）； 平均每次统计业务产生90个事务（T3）；

一天内忙时的处置量为平均值的5倍；体会系数为1.6；(实际工程体会);考虑效劳器保留30％的冗余；

效劳器需要的处置能力为：

TPC-C=U1*N1*(（T1+T2+T3）/3)*5*体会系数/冗余系数 那么处置性能估算为：

TPC-C=16*3*(20*4+50*5+90*1)/10*5*1.6/0.7=

16*3*42*5*1.6/0.7=23040tpmC=24000tpmC 1.1.1.2.3 报表和统计分析性能需求

用户数30 (U1)

平均每一个用户每分钟发出3/1440次业务请求（N1）； 系统发出的业务请求中，更新、查询、统计比例为 0:3:7； (无)平均每次更新业务产生20000个事务（T1）； 平均每次查询业务产生40000个事务（T2）； 平均每次统计业务产生90000个事务（T3）；

一天内忙时的处置量为平均值的5倍；体会系数为1.6；(实际工程体会);考虑效劳器保留30％的冗余；

效劳器需要的处置能力为：

TPC-C=U1*N1*(（T1+T2+T3）/3)*5*体会系数/冗余系数 那么处置性能估算为：

TPC-C=30*3/1440*(40000*3+90000*7)/10*5*1.6/0.7= 30*(3/1440)*75000*5*1.6/0.7=53571.42tpmC=55000tpmC

总性能需求=业务处置性能+接口处置性能(基础数据+业务数据)+报表统计分析

=700,00tpmC+（22tpmC+24000tpmC)+55000tpmC =149022tpmC =15万tpmC

1.1.2 应用效劳器

由于单个效劳器的处置能力所能承担的网络连接数和进程数是有限的，超过必然限度后系统会因为大量进程间的频繁调度而使整体性能急剧下降，因此建议本系统采纳三层结构，配置专门的应用效劳器。应用效劳器上运行中间件产品（本系统采纳J2EE中间件），集中承担业务逻辑的实现，并处置与数据库的连接。中间件能够通太高速数据通道机制，减少客户机与主机和数据库的连接，降低网络负担，提高主机处置能力，提高数据库效率。同时中间件的系统负载均衡机制，能最有效地运用系统资源，因此采纳中间件能够大大降低前台终端对数据库效劳

器的冲击，它的处置量要紧表此刻联机事务处置和一些计算上。依照体会，基于J2EE的应用效劳器处置能力一样为数据库效劳器的70%，应用效劳器的内存容量与提供效劳的进程个数及其内存开销紧密相关，通常，J2EE应用效劳器的内存容量建议高配置。

系统实际运行时，其处置能力为数据库效劳器的70%，计算出结果为其 TPC-C值为15万*70%= 10万tpmC

1.1.3 数据存储

依照理想公司历史数据为例 ：

10年 累计 3.5万项目，平均每一个项目6M数据需要存储，其中数据1M，附件5M。

1.1.3.1 数据库部份

从第一年开始6000个项目，按20%的量递增，同时考虑历史的存量数据35G。

时间 评估内容 项目数量 新数据容量 历史数据容量

第一年 6000 6G 35G 第二年 7200 7G 35G 第三年 80 8G 35G 第四年 10368 10G 35G 第五年 12441.6 12G 35G 依照系统平台规模需求预测，系统每一年业务数据量为9G，计算出5年后，系统中的要紧业务数据为78GB。此数据寄存在磁盘阵列的数据库内。

考虑其他进程性数据，如日记等记录，和统计报表类的数据，加上其他应用数据，其数据量可按要紧进程性业务数据总量的60%计，总的数据存储容量需求为：(1 + 60%) *78GB ≈ 125GB。

1.1.3.2 附件部份

从第一年开始6000个项目，按20%的量递增。

时间 评估内容 项目数量 附件容量 历史容量

第一年 6000 30G 175G 第二年 7200 36G 175G 第三年 80 43G 175G 第四年 10368 52G 175G 第五年 12441.6 62G 175G 附件累计：298GB，可能为300G

1.1.4 备份需求估算

就目前平台网络及效劳器设备情形和数据量的情形而言，系统要紧数据备份需求为系统数据库存储业务数据的备份，而从逻辑形式上分，数据库的备份要紧分为两种，一种是物理备份，主若是对数据库的数据文件、日记文件、操纵文件进行备份，它需要利用数据库的备份工具；另一种备份为逻辑备份，是表一级的备份。通常情形下，大型数据库的备份以物理备份为主，逻辑备份为辅，因为物理备份恢复速度快。物理备份又分为在线备份和脱机备份两种。在线备份是在数据库运行的情形下实施的备份，而脱机备份那么是在数据库关闭的情形下进行。而关于7×24的数据库只能进行在线备份。在本系统中咱们建议采纳在线备份方式。

平台数据库进行逻辑备份，逻辑备份的数据保留在应用效劳器上，天天进行一次针对业务数据的备份，备份副本保留三天，估量5年后一次逻辑备份约需要80G，保留三天副本需要240G备份空间。

通过编写打算任务拷贝的方式，对应用效劳器上的附件，进行备份，将磁盘阵列数据备份至应用效劳器本机磁盘上。每周进行一次全备份，估量5年后一次全备份约为300G。

备份的总空间= 数据库逻辑备份+附件备份 =240+300=0G

1.2 硬件物理拓扑图

系统网络结构应用服务器2数据库服务器文件服务器WEB服务器应用服务器1核心网络...统一认证服务收入系统门户综合业务网核心交换机终端用户终端用户终端用户 1.3 硬件配置需求

数据库效劳器 15万tpmC 应用效劳器 10万tpmC

1.3.1 应用效劳器

硬件需求 应用服务器 应用服务器 文件服务 应用服务器A 应用服务器B+数据库备份(逻辑备份+附件备份） 文件服务器(利旧) CPU 2核 内存 8G 硬盘 50G 网络 1Gbps 2核 8G 50G+0G 500G 1Gbps 1Gbps 器 Web服务器 Apache Http Server 2.2

2核 4G 20G 1Gbps 1.3.2 数据库效劳器

数据库服务器

Mysql数据库服务器(物理机) CPU核数 2核 内存 6G 存储空间 200G 网络带宽 1Gbps 1.4 软件配置要求

软件需求 应用服务器 应用服务器 文件服务器 Web服务器 数据库服务 数据库服务

服务器A 服务器B 服务器C 服务器D 服务器E 服务器F 操作系统 Linux bit Linux bit Linux bit Linux bit Linux bit Linux bit 中间件 TOMCAT bit TOMCAT bit 其他软件 vsftp Apache Http Server 2.2 Mysql 5.5 bit 企业版 Mysql 5.5 bit 企业版 1.5 软件逻辑拓扑图

虚拟化部署方式文件服务器附件FTP应用服务器A应用服务器A1WEB服务器应用服务器A2HTTP 服务器1MOD代理数据库服务器应用服务器BDB_BAK应用服务器B1MySQL 数据库应用服务器B2