|
||||||||||||||||||
结论：以采购入库单制单为例，当并发数40-80，其平均响应时间为60-100秒，但100并发时，平均响应时间不再线性增加而是已经翻番了，说明系统资源已经不能应付80并发以上的工作压力了。 |
||||||||||||||||||
 |
||||||||||||||||||
|
||||||||||||||||||
测试简介：
测试采用的是数据量是大小为5G的数据库，这里需要说明一下的是5G数据库的真正含义，测试用的数据库表示浪潮PS各个功能模块中涉及的物料字典、往来单位记录、出入库单据、帐本、凭证单据和销售发票等等各种数据记录表单。由于硬件配置较低，我们只打算测试5G的数据库，5G的数据库，光是销售发票就有张之多，出库单数量是张，其他的各种单据都在30万张以上。假如单张销售发票面额是1000元，这个5G的数据量已经代表了一个营业额过亿的中等规模的加工贸易型企业了。可以想像，这样规模的企业应该是不会使用这种配置的服务端了，现实中的中小型企业或许不会有那么大的业务数据量，但我们进行的是ERP压力测试，只从极端的情况来考虑，当一个企业的业务量激增，而系统环境还来不及升级的情况下，就能体现出这些系统应对巨大压力时的价值了。
还有需要和大家先说明的是并发数，同样大小的测试数据库下，我们用增加并发数来体现压力的增加，直至并发过多最后使系统瘫痪，以次来确定各个系统的承受极限以及相应的TPS。并发动作好比我们日常工作中的某个一个具体业务创作，从客户端向服务端发出一个业务请求，作为一个并发动作，当服务端解决并返回业务操作结果，视为一个完整的事务（Transaction）。根据各个测试模块的具体动作，则事务的复杂程度也是有所不同的。就象现实中的企业运作一样，库房收取入库产品，做入库单据；而同一时间，会计也在统计帐页，查询各往来单位的收付情况。混合测试就是多项业务功能客户端在同一时间向ERP的数据库提出业务请求，具体的数量就是我们设定的并发数。一家企业由多个客户机形成数量大小不同的客户端，日常或许同时有20、30人在线，而向服务器发出业务申请的可能只有10个以下，这里就是我们所定义的并发用户数。向相关人士了解，现实中的中小型企业，客户端在40到50个以下，日常工作的并发数大概在5-10个左右，突发的并发数不超过20个，当这样的企业要应付40个左右的并发数时已经是忙得焦头烂额了。当并发数过大时，系统资源主要用于大量的运算处理，对客户端返回结果的其响应时间（Responding Time）就会大大加长。
即便没有产生等待超时的死锁进程，如果完成事物的响应时间过长，这样的结果也是没有什么参考价值的。因为曙光A440r-F是配置较低的入门级服务器，让它是处理100个以上的并发测试，其实已经没有什么实际意义了。
数据分析：
物流模块1、采购入库单制单：采购物资入库时制作采购入库单，仓库保管员确认无误后对单据所指标物料、产品做入库操作。大致业务流程：采购模块－入库－采购入库单维护（见图1、2）。采购入库单制单，在实际的PS-ERP操作中，操作员会对往来单位、物料编码字典做相应的选择，对于没有可选的单位则进行手工输入，最后保存单据，在实际的操作中，视乎数据量的多少，完成一个制单或许需要3-5分钟左右，这里面主要是操作人员的思考和输入时间。而在测试中，人的时间可以缩短到基本已经可以忽略不加考虑，结果反应的更多是系统的响应时间。在 采购入库单制单模块中，当并发数40-80，其平均响应时间为60-100秒，但100并发时，平均响应时间不再线性增加而是已经翻番了，说明系统资源已经不能应付80并发以上的工作压力了。
注： Std.Deviation是标准系统偏差，是量度数据分布的分散程度的标准，用以衡量数据偏离算术平均值的程度。标准偏差越小，这些值偏离平均值就越少，反之亦然。标准偏差的大小可通过标准偏差与平均值的倍率关系来衡量。
图1 采购入库单制单结果
图2 采购入库单制单执行步骤结果
物流模块2、客户欠款余额查询：对某一期间段内的客户、部门或人员的欠款进行查询。大致业务流程：应收模块－查询－应收账页－客户欠款余额查询（见图3、4）。对于客户欠款余额查询，随并发数的增加，平均响应时间的增长还算保持一定比例，可以说明该功能模块对系统没有很难承受的压力。但100并发时完成一个查询动作所需要等待的差不多4分钟，也已经接近我们的能接受极限了。
图3 客户欠款余额查询结果
图4 客户欠款余额查询执行步骤结果
模块3、库存辅助管理余额查询：对使用辅助项的物料进行余额账查询，大致业务流程：库存模块－账表－账簿查询－辅助管理余额查询（见图5、6），和上面的各模块一样，100并发的时间让人有点难以接受，在联查单据时出现了Fail，可以说，这个模块的测试数据在100并发时已经是不可用了，要保证工作运行正常必须要添加硬件配置了。
图5 库存辅助管理余额查询结果
图6 库存辅助管理余额查询执行步骤结果
模块4、库存入库单记帐：采购物料到货后制作采购入库单，需要通过入库单记账功能以将其登记到账本中。大致业务流程：库存模块－业务－入库－入库单登记库存账（图7、8），经过操作，入库单将由帐前状态转为帐后状态。从结果上看出，80并发以下的测试数值还可以接受。
图7 库存入库单记帐结果
图8 库存入库单记帐执行步骤结果
模块4、全月加权成本计算：全月加权成本计算是对计价方法为全月加权成本计算的物料进行成本计算，大致业务流程：存货核算－业务－出库成本计算－全月加权成本计算（图9、10）。
图9 全月加权成本计算结果
图10 全月加权成本计算执行步骤结果
模块5、销售提货单制单：该单据是客户到仓库部门提货和库管员发货的依据。大致业务流程：销售模块－业务－普通业务处理－提单业务处理－回收提单制单。（结果见图11、12）。
测试结果看到现在我们已经大致了解，这台服务器的工作压力极限是在80并发数左右。但能够想象，如果同一时间多客户机向服务器发的业务请求超过80，这样的企业应该会选用更加高配置的服务器的。
图11 销售提货单制单结果
图12 销售提货单制单执行步骤结果
图13 帐务混合测试（80并发）
图14 系统占用资源
从结果可以看出这样低端配置的服务器运行这样的压力测试，当并发数接近100时已经有些力不从心，涉及到数据库大量查询索引时，有些任务象帐务的科目余额查询模块的等待时间已经超过了800秒(图13)，此时CPU占用率已被逼到100%（图14）,超过100并发时也出现了预料之中的transaction fail。可见数据的压力已经接近或超过了硬件的极限，这里已经出现处理器瓶颈。
图15 各模块平均响应时间
各模块对数据库的压力大小有所区别，表现出来的响应时间从会有很长差异（图15），这里关键视乎用户的接受程度。象某些使用任务量繁重但使用较少的功能模块，如月结、年度数据查询等涉及大量数据库调用和系统运算资源的模块，这样需要用户在实际应用合理的分配系统资源，以求负载平衡。
图16 TPS
小数据库混合测试结果显示每秒平均处理事务数3.379（图16），相对于经过认证的SAP-SD基准测试动辄数千的TPS，是显得少了点，但试想下，那些服务器大厂用来测试的硬件都是不惜血本只为了不断把成绩刷新哪怕只要1%。相形之下，PConline ERP压力测试小组手上的服务器真的十分简陋。
小结：
另外，SAP-SD的测试其实是个单模块独立测试，和本次ERP压力测试的多模块混合测试其实没有什么可比性，表面上我们只抽取了物流功能6模块帐务功能3模块一共9大模块，但实际上浪潮ERP-PS的业务环节之间都有着或多或少的联系，测试平台的软件都是选全部安装，测试用的帐套数据库也是包括全部功能模块的，我们所选取的9个核心业务模块在后台数据是有着更加广泛联系和调用。混合测试的总共测试动作步数和SAP-SD也不在一个数量级上。所以在曙光A440上的结果也符合我们先前的预测，在这个硬件平台上达到80并发的极限已经是可以接受的结果。
到此这篇服务器压力测试是什么意思啊（服务器压力测试报告）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/te-aq/25670.html