|
1回顶部
测试简介： 本次测试所使用的服务器是
曙光天阔A830r-F内景
曙光天阔A830r-F内景 测试采用的是数据量是大小为5G的数据库，这里需要说明一下的是5G数据库的真正含义，测试用的数据库表示浪潮PS各个功能模块中涉及的物料字典、往来单位记录、出入库单据、帐本、凭证单据和销售发票等等各种数据记录表单。由于硬件配置较低，我们只打算测试5G的数据库，5G的数据库，光是销售发票就有137754张之多，出库单数量是346430张，其他的各种单据都在30万张以上。假如单张销售发票面额是1000元，这个5G的数据量已经代表了一个营业额过亿的中等规模的加工贸易型企业了。可以想像，这样规模的企业应该是不会使用这种配置的服务端了，现实中的中小型企业或许不会有那么大的业务数据量，但我们进行的是ERP压力测试，只从极端的情况来考虑，当一个企业的业务量激增，而系统环境还来不及升级的情况下，就能体现出这些系统应对巨大压力时的价值了。 还有需要和大家先说明的是并发数，同样大小的测试数据库下，我们用增加并发数来体现压力的增加，直至并发过多最后使系统瘫痪，以次来确定各个系统的承受极限以及相应的TPS。并发动作好比我们日常工作中的某个一个具体业务创作，从客户端向服务端发出一个业务请求，作为一个并发动作，当服务端解决并返回业务操作结果，视为一个完整的事务（Transaction）。根据各个测试模块的具体动作，则事务的复杂程度也是有所不同的。就象现实中的企业运作一样，库房收取入库产品，做入库单据；而同一时间，会计也在统计帐页，查询各往来单位的收付情况。混合测试就是多项业务功能客户端在同一时间向ERP的数据库提出业务请求，具体的数量就是我们设定的并发数。一家企业由多个客户机形成数量大小不同的客户端，日常或许同时有20、30人在线，而向服务器发出业务申请的可能只有10个以下，这里就是我们所定义的并发用户数。向相关人士了解，现实中的中小型企业，客户端在100到200个左右，日常工作的并发数大概在30-50个左右。当并发数过大时，系统资源主要用于大量的运算处理，对客户端返回结果的其响应时间（Responding Time）就会大大加长。即便没有产生等待超时的死锁进程，如果完成事物的响应时间过长，这样的结果也是没有什么参考价值的（相关说明见本站文章“微软、浪潮工程师谈ERP压力测试”）。 本轮测试的服务器服务器是配置较高的企业级服务器，使用AMD四路双核，16G内存，存储系统为4块15，000转的73G硬盘组成的硬件RAID5（系统详情见图1）。 图1 系统资源 2回顶部 数据分析： 物流模块1、采购入库单制单：采购物资入库时制作采购入库单，仓库保管员确认无误后对单据所指标物料、产品做入库操作。大致业务流程：采购模块－入库－采购入库单维护（见图2）。采购入库单制单，在实际的PS-ERP操作中，操作员点右键调出往来单位、物料编码字典的选择菜单，做相应的选择。对于没有可选的单位则进行手工输入，最后保存单据，在实际的操作中，视乎数据量的多少，熟练的ERP操作员完成一个制单动作，需要5分钟左右，这里面主要是操作人员的思考和输入动作的时间。而在测试中，人的时间可以缩短到基本已经可以忽略不加考虑，结果反应的基本全部是系统的响应时间。在采购入库单制单模块中，当并发数在100-200时，其平均响应时间只有40-70秒。并发在220时，平均响应时间超过80秒，此结果仍在可接受范围之内。参考上一篇引起很多争议的测试报告“Intel单路4核服务器”，单路4核的CPU在140并发时该模块的响应时间接近100秒，4颗CPU的测试性能理所当然超越单路4核。 图2 采购入库单制单结果（点击查看大图） 物流模块2、客户欠款余额查询：对某一期间段内的客户、部门或人员的欠款进行查询。大致业务流程：应收模块－查询－应收账页－客户欠款余额查询（见图3）。对于客户欠款余额查询，随并发数的增加，平均响应时间的增长保持一定比例，随并发压力的增加响应时间逐渐变慢，最长响应时间在100秒左右，可以说明该功能模块对系统没有很难承受的压力。 图3 客户欠款余额查询结果（点击查看大图） 物流模块3、库存辅助管理余额查询：对使用辅助项的物料进行余额账查询，大致业务流程：库存模块－账表－账簿查询－辅助管理余额查询（见图4）。该模块可以说对并发压力增加的表现出直观的敏感，并发从100—220的不断累加，其响应时间呈现线性增加，220并发的平均响应时间恰好超过150秒，这时间与单路4核140并发的响应时间很接近，这里可以大致的看出两套系统的性能差异。 图4 库存辅助管理余额查询结果 3回顶部 物流模块4、库存入库单记帐：采购物料到货后制作采购入库单，需要通过入库单记账功能以将其登记到账本中。大致业务流程：库存模块－业务－入库－入库单登记库存账（图5），经过操作，入库单将由帐前状态转为帐后状态。从结果上看出，各个并发数状态以下的平均响应时间平均在20-30秒之间，和采购入库单制单模块相类似，该模块对系统造成的压力不大。220并发时出现了最长响应超过120秒，最长和最短的响应时间差别过大，由此会造成标准差数值偏离正常范围，220并发下，系统对压力的敏感度已经很高了，在较大的压力下，某些事务的执行会变得缓慢。 图5 库存入库单记帐结果（点击查看大图） 物流模块5、全月加权成本计算：全月加权成本计算是对计价方法为全月加权成本计算的物料进行成本计算，大致业务流程：存货核算－业务－出库成本计算－全月加权成本计算（图6）。压力在200并发以上时，平均响应时间才超过40秒，这和库存入库单记帐模块一样，对系统的负载压力并不大。但并发220的时候，受其他模块的影响，全月加权成本的最长响应时间接近180秒。又是一个标准差偏离的体现，系统的整体表现不稳定，我们推测这里存在软件的设计性能极限的因素。浪潮PS-ERP是针对中小型企业而设计开发的ERP系统，在实际应用中极少有超过100并发的，200并发除了在这次压力测试更是闻所未闻。 图6 全月加权成本计算结果（点击查看大图） 物流模块6、销售提货单制单：该单据是客户到仓库部门提货和库管员发货的依据。大致业务流程：销售模块－业务－普通业务处理－提单业务处理－删除提单。（结果见图7）。本模块所占的系统压力比例不大，100-200并发的平均响应时间仍在合理，可接受范围之内。220并发的响应时间多少有些强差人意。 4回顶部 帐务混合模块1，凭证制单（图8），这里出现了比较奇怪的现象，平均响应时间相对于单路双核（40-100并发，80-160秒）和单路四核（100-140并发，60-100秒）都要慢。说句废话，理论上配置越高，模块的响应速度应该是更快的但在这里我们得到了不合逻辑的结果。 图8 凭证制单（点击查看大图） 帐务模块2：凭证记帐（图9），和上面的凭证制单一样，其响应时间也相对的变慢，不过幅度没有凭证制单差别的那么大。同样，我们带着问号往下看。 图9 凭证记帐（点击查看大图） 在经过详细的分析对比和咨询过浪潮ERP相关的工程师后，我们觉得大致找到了这两个模块变慢的原因。我们对比了前后测试的脚本和场景设计后发现，在Vusers（虚拟并发用户）加载的设置中，两套系统的测试场景测试并不一样（见图10）。在单路4核的服务器上140个并发用户是同时加载，在测试过程开始的同时已经加载全部并发。而这一次的测试是按照每5秒10个并发进行分步逐渐加载的。正因为这是两个对系统没有很大压力的模块，不同的并发速度会导致很多的结果，直接影响结果的因素如各模块有优先顺序以及对系统资源的占用和抢夺，由此形成的数据队列长度以及数据锁的数量等多种不确定因素。据浪潮ERP高工程师的介绍，凭证制单和记帐这两个模块对系统不会形成很大的负载压力，正是如此，在高并发压力下，系统资源被其他模块大量占用，如果凭证制单和记帐模块的并发用户没有等待队列优势的时候，其响应时间就会大幅度增加。 图10 并发用户加载速度（点击查看大图） 5回顶部 从已经发布的测试报告中我们知道系统最大负载集中在科目余额查询当中，科目余额查询也是响应时间最长的一个模块。在测试中平均的响应时间在260--350秒之间。不过这相对于之前公布的单路4核140并发800秒的响应时间，单一个模块的响应时间比较快也不能说明这套系统的整体性能，但综观整个测试结果，给我们的感觉就是比较均衡在9个模块的混合测试中，其中7个都得到了最快的响应时间，可以说这个系统的测试结果是相当优秀。 图11 科目余额查询（点击查看大图） 也许有人会问，一个查询需要5、6分钟也不算很快了，其实科目余额查询的定义不算大准确，正确的理解，科目余额查询应该是一个生成报表的功能模块。采访过浪潮的工程师之后我们了解到，科目余额查询和凭证制单、记帐的复杂程度完全不一样，科目余额查询是按条件生成报表的一个查询动作。不同的查询条件，比如查询时段长短或按月按日汇总结果等不同查询条件所产生的报表内容长短大小会差别很大，所需要的计算时间也会相差巨大，耗损时间和系统资源占用也会差别很多，查询所得结果会生成大小不同的报表。科目余额查询是ERP系统中与其他模块密切集成、相关的主要模块，它的原始数据绝大部分来源于其他模块，又深入到其他模块的控制过程中，其操作内容表面上简易，但所涉及到的项目科目后台列表、查询动作也比较频繁，当并发用户大幅度增加时对数据库的负荷压力会有明显影响。 相对于先前给出的测试结果，这里的测试成绩还是可以接受的，单路双核80并发、单路4核140并发的响应时间为800秒，在本系统上得到的测试结果也是我们到现在所得到的最好的结果了。 6回顶部 小结： 图12 系统资源占用(点击查看) 从图12看出，系统资源在各种并发压力下并没有充分被调用，较高的硬件配置对系统的负载压力还是能应付自如，平均CPU占用只在80%-85%之间。存储系统的系统资源也平稳的保持在一个较低的水平，也没有出现在单路4核服务器上突然爆涨的磁盘占用（见图13），这里部分体现了RAID5和RAID1磁盘阵列的性能差别，不同大小的物理内存也会有不一样的性能表现。16G的物理内存可以直接把需要调用的大量数据放在内存中，这样可以减少了很多磁盘的读写操作。我们觉得这套四路双核在硬件的配置上比较均衡，不存在比较明显的硬件性能瓶颈。 图13 单路四核服务器系统资源占用
图14 各压力下的TPS 本次测试的100-220的各种并发项目下的平均TPS都在10以上（图14），最高的12.681TPS产生在200并发下，这个成绩比单路4核的测试数值（8.6TPS）有48%的提升。当并发增加到220的时候，TPS开始下降到10.949，也就是说200并发的压力是本套系统的最佳运行状态。购买这样的一套服务器系统，基本可以满足200个左右并发用户的业务量压力，这对国内的中小生产型或流通型的企业，也是很大的一个业务量，在采访过浪潮通软的工程师后，我们了解到在实际的ERP用户中其实还没有出现过200并发的系统压力，根据浪潮通软PS-ERP实际使用的经验值，200个并发大约相当于一个企业600个在线用户，接近上千的信息点。这样的规模已经超出了PS-ERP的服务范围。 反过来说，浪潮通软PS-ERP的效能还是比较高的。从入门级服务器支持80个并发，到单路4核支持140个并发，以及在双路双核上支持160个并发。使用浪潮通软PS-ERP+微软SQL 2005这套解决方案，对硬件平台的适应性还是非常好。对中小企业的信息化投入也不会造成很大的压力。
|
||||||||||||||||||||||||||||||||||
正在阅读：ERP压力实测 曙光四路双核A830r-F胜似闲庭信步ERP压力实测 曙光四路双核A830r-F胜似闲庭信步
2007-11-16 09:08
出处：PConline原创
责任编辑：heyaorong
