|
1回顶部
测试简介： 测试采用的是数据量是大小为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、采购入库单制单：采购物资入库时制作采购入库单，仓库保管员确认无误后对单据所指标物料、产品做入库操作。大致业务流程：采购模块－入库－采购入库单维护。采购入库单制单，在实际的PS-ERP操作中，操作员点右键调出往来单位、物料编码字典的选择菜单，做相应的选择。对于没有可选的单位则进行手工输入，最后保存单据，在实际的操作中，视乎数据量的多少，熟练的ERP操作员完成一个制单动作，需要5分钟左右，这里面主要是操作人员的思考和输入动作的时间。而在测试中，人的时间可以缩短到基本已经可以忽略不加考虑，结果反应的基本全部是系统的响应时间。在采购入库单制单模块中，平均响应时间与并发数成比例增长，且整个增长过程呈较平坦直线。当并发数在140-180时，其平均响应时间为65-100秒。并发在200时，平均响应时间稍微超过100秒。对于双路双核的配置来讲，此表现很正常，除了200并发数的成绩，其余仍在可接受范围之内。在之前的单路四核测试中，140并发的响应时间就接近100秒了。
物流模块2、客户欠款余额查询：对某一期间段内的客户、部门或人员的欠款进行查询。大致业务流程：应收模块－查询－应收账页－客户欠款余额查询。对于客户欠款余额查询，按照设想，应该是随并发数的增加，平均响应时间的增长保持一定比例，随并发压力的增加响应时间逐渐变慢，但在实际测试中，发现有点出入，在140并发数时，响应时间略微过了100秒，但在160并发数时，反而下降不少，响应时间只有80秒左右，接着在180和200并发时，又超过100秒。
物流模块3、库存辅助管理余额查询：对使用辅助项的物料进行余额账查询，大致业务流程：库存模块－账表－账簿查询－辅助管理余额查询。这个模块也是压力较大的一部分，从140开始，响应时间就在150秒上下。到200并发时，更是已经接近200秒。与单路4核的表现基本持平。
物流模块4、库存入库单记帐：采购物料到货后制作采购入库单，需要通过入库单记账功能以将其登记到账本中。大致业务流程：库存模块－业务－入库－入库单登记库存账，经过操作，入库单将由帐前状态转为帐后状态。从结果上看出，各个并发数状态以下的平均响应时间平均在20-40秒之间，该模块对系统造成的压力不大。
物流模块5、全月加权成本计算：全月加权成本计算是对计价方法为全月加权成本计算的物料进行成本计算，大致业务流程：存货核算－业务－出库成本计算－全月加权成本计算。响应时间在各个并发数上的差距并不大，在140并发时，响应时间为70秒左右，在200并发时，也才接近100秒，对系统的负载压力并不算很大，只是与采购入库制单相似。
物流模块6、销售提货单制单：该单据是客户到仓库部门提货和库管员发货的依据。大致业务流程：销售模块－业务－普通业务处理－提单业务处理－删除提单。。虽然在之前的单路四核中，该模块对系统的压力稍微有点大，但还是在可接受的范围之内，不过这次在双路双核的配置中，却让系统感受到了较大的压力，除了在140并发时响应时间在180秒左右之外，160-200并发数下的响应时间均超过了200秒，在200并发时，更是超过了250秒。反观单路四核，在160并发时也才155秒左右的响应时间。这次确实让我们始料未及。
回过头过，我们再看一下整个物流模块的各并发下TPS（每秒事务处理数）变化情况： 在平均TPS上，可以看到是呈一条相当平直的曲线，从140并发时的8.782到200并发时的9.863，只相差了1.081。可见随着并发数的增加，事务处理量没有成正比例上升。而看一下最高TPS这条曲线，可以发现起伏比较大，在160并发时达到最高的23.75TPS。因此，综合两条曲线和前面的成绩，特别是在“库存辅助管理余额查询”所呈现的较明显变化，我们初步预测160并发是这台双路双核配置发挥最佳性能的压力环境。
帐务模块： 接下来是帐务混合模块测试： 帐务混合模块1，凭证制单。凭证制单对系统的压力也不少，从140并发开始，响应时间就超过了100秒，但是随着并发数的增加，并没有再变慢，在140并发时的比较，比单路四核略微慢一些。
帐务模块2：凭证记帐，这一模块表现也是很正常，140和160并发时50秒的响应时间，180并发时略微升高的响应时间，都是在接受的范围之内，也与单路四核的测试结果几乎一样。
帐务模块3：科目余额查询。科目余额查询在这次压力测试活动中，一直是整个测试过程中压力最大的一部分。这次双路双核也在意料之内，140并发和160并发时，响应时间达到了750秒左右，而在180并发时，更是达到了870秒左右的响应时间，这样的成绩，在日常工作时，确实会让人等待较长时间，不过这是在140并发以上的测试，而对于一台双路双核的服务器来说，在中型企业中接受这种并发下的查询是极少。
最后我们还是来看下帐务模块的TPS情况： 这次平均TPS的曲线很明显，在160并发时平均TPS达到最高3.043，而在180并发时，虽然最高TPS达到了13，但在平均TPS这条曲线上，已经开始往下掉，所以我们再一次验证了在160并发时，这台双路双核服务器能够达到最佳效能。
总结： 下面是四个并发状态下的系统主要资源使用图，可以看到，在140并发时，CPU没有达到很高的使用率，系统内存使用率也处于一个逐步提升的态势，明显140并发并不是该双路双核硬件配置的压力承受极限。在160并发时，系统资源使用率就提高了许多，基本上CPU达到90%以上的使用率，系统内存使用率也在初期一个迅速爬升后处于稳定状态。而到了180并发和200并发时，系统资源使用率没有发生多大改变，因为CPU跟在160并发下一样，已经接近了使用率的顶峰。这个表现，一方面表明160并发确实是硬件的一个最佳效能发挥环境，同时也说明了浪潮PS-ERP能够很好地“压榨”硬件性能，有效利用企业的硬件投资。
|
|||||||||||||||||||||||||||||||||
正在阅读：资源利用率是关键--AMD双路双核ERP压力测试资源利用率是关键--AMD双路双核ERP压力测试
2007-11-21 16:14
出处：
责任编辑：xiexiaomian
