参考文档---系统能力需求估算.docx_第1页
参考文档---系统能力需求估算.docx_第2页
参考文档---系统能力需求估算.docx_第3页
参考文档---系统能力需求估算.docx_第4页
参考文档---系统能力需求估算.docx_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1.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 基础数据接口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.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.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万tpmC1.1.2 应用服务器由于单个服务器的处理能力所能承担的网络连接数和进程数是有限的,超过一定限度后系统会因为大量进程间的频繁调度而使整体性能急剧下降,因此建议本系统采用三层结构,配置专门的应用服务器。应用服务器上运行中间件产品(本系统采用J2EE中间件),集中承担业务逻辑的实现,并处理与数据库的连接。中间件可以通过高速数据通道机制,减少客户机与主机和数据库的连接,降低网络负担,提高主机处理能力,提高数据库效率。同时中间件的系统负载均衡机制,能最有效地运用系统资源,因此采用中间件可以大大降低前台终端对数据库服务器的冲击,它的处理量主要表现在联机事务处理以及一些计算上。根据经验,基于J2EE的应用服务器处理能力一般为数据库服务器的70%,应用服务器的内存容量与提供服务的进程个数及其内存开销密切相关,通常,J2EE应用服务器的内存容量建议高配置。系统实际运行时,其处理能力为数据库服务器的70%,计算出结果为其TPC-C值为15万*70%= 10万tpmC1.1.3 数据存储根据理想公司历史数据为例 :10年 累计 3.5万项目,平均每个项目6M数据需要存储,其中数据1M,附件5M。 数据库部分从第一年开始6000个项目,按20%的量递增,同时考虑历史的存量数据35G。 时间评估内容建议不要出现空单元格第一年第二年第三年第四年第五年项目数量6000720086401036812441.6新数据容量6G7G8G10G12G历史数据容量35G35G35G35G35G根据系统平台规模需求预测,系统每年业务数据量为9G,计算出5年后,系统中的主要业务数据为78GB。此数据存放在磁盘阵列的数据库内。考虑其他过程性数据,如日志等记录,以及统计报表类的数据,加上其他应用数据,其数据量可按主要过程性业务数据总量的60%计,总的数据存储容量需求为:(1 + 60%) *78GB 125GB。 附件部分从第一年开始6000个项目,按20%的量递增。 时间评估内容第一年第二年第三年第四年第五年项目数量6000720086401036812441.6附件容量30G36G43G52G62G历史容量175G175G175G175G175G附件累计:298GB,大概为300G1.1.4 备份需求估算就目前平台网络及服务器设备情况以及数据量的情况而言,系统主要数据备份需求为系统数据库存储业务数据的备份,而从逻辑形式上分,数据库的备份主要分为两种,一种是物理备份,主要是对数据库的数据文件、日志文件、控制文件进行备份,它需要使用数据库的备份工具;另一种备份为逻辑备份,是表一级的备份。通常情况下,大型数据库的备份以物理备份为主,逻辑备份为辅,因为物理备份恢复速度快。物理备份又分为在线备份和脱机备份两种。在线备份是在数据库运行的情况下实施的备份,而脱机备份则是在数据库关闭的情况下进行。而对于724的数据库只能进行在线备份。在本系统中我们建议采用在线备份方式。平台数据库进行逻辑备份,逻辑备份的数据保存在应用服务器上,每天进行一次针对业务数据的备份,备份副本保存三天,估计5年后一次逻辑备份约需要80G,保存三天副本需要240G备份空间。通过编写计划任务拷贝的方式,对应用服务器上的附件,进行备份,将磁盘阵列数据备份至应用服务器本机磁盘上。每周进行一次全备份,估计5年后一次全备份约为300G。备份的总空间= 数据库逻辑备份+附件备份 =240+300=540G1.2 硬件物理拓扑图1.3 硬件配置需求数据库服务器 15万tpmC应用服务器 10万tpmC1.3.1 应用服务器硬件需求CPU内存硬盘网络应用服务器应用服务器A2核8G50G1Gbps应用服务器应用服务器B+数据库备份(逻辑备份+附件备份)2核8G50G+540G1Gbps文件服务器文件服务器(利旧)500G1GbpsWeb服务器Apache Http Server 2.22核4G20G1Gbps1.3.2 数据库服务器CPU核数内存存储空间网络带宽 数据库服务器Mysql数据库服务器(物理机)2核6G200G1Gbps1.4 软件配置要求软件需求操作系统中间件其他软件应用服务器服务器ALinux 64bitTOMCAT 64bit应用服务器服务器B

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论