问：第一次和浪潮ERP接触的时候，浪潮的焦总特别介绍了这个浪潮的ERP是每年将上一年平时不常用的那种数据的归档,相当于把它放在另一个数据库里。所以即使连续使用了几年浪潮ERP的情况下，如果企业规模变化不大,它的数据库不会线性增长，业务量增长不大的时候,数据的规模不会变化太大。我们刚开始测试的时候，那时候拿到的原始数据只有1G大小。而后来我们测试的标准数据量是5G，请问高工,在你们典型的客户当中,就是最常用的一般的企业客户,他的数据库大小大概有多大呢?
高:一般的企业如果业务量较大的话，数据库会在2-3G左右，很大的企业可能稍微再增长一部分,但是最大应该是不会超过5G的。
问：那实际上就是说不要谈20G、50G，5G数据库在实际使用中已经是很大的一个数据量了，对吗？
高:是的，实际上我们的客户的数据库没有超过5G的。这次采用这么大的数据库主要也是为了增加系统的压力。
张：除了上面提到的会影响到测试成绩的各种因素，ERP系统其实尤为管理SQL2005还提供了很多保证系统高稳定性的一些功能.比如说, SQL2005支持在线的重建、修改索引，在线快速恢复和还原数据库等等操作。SQL2005的主动通知功能和数据库镜像的功能，可以保持数据库的缓存数据刷新和避免双机热备的单点故障，等等这些都是对系统稳定的一些很好的保障。SQL2005的性能优化顾问和动态管理视图，可以随时检测系统资源的占用情况，并对占用资源较多的SQL语句记录和优化，在性能优化顾问中给出优化的建议（SQL2005相关新功能参考“SQL Server 2005性能测试概览及功能简析”）。浪潮PS-ERP的开始是基于SQL2000的平台上，如果能对SQL2005众多的新功能予以支持，其运行的性能相信还会得到提高。
问：感谢两位工程师解释了性能测试中的一些问题，我也顺便说一下我们测试中的一些情况。刚才刚才张伟杰提到的性能均衡问题，我们在测试中也发现了。有台服务器准备一路双核CPU、2G内存，但磁盘是SATA硬盘的入门级的服务器。在上面我们最高测试了80个并发，在内存同样是2G但装1颗四核CPU的另一台服务器测试成绩就比较好。这两台机器对比性能的话。后者物流并发数达到了140，TPS比前者提高了157%。实际上这并不完全是CPU性能提升带来的测试结果差别，后一个系统装了SAS磁盘组成的硬件RAID1，测试结果的差别很大的因素在于磁盘IO。从测试结果的系统磁盘性能数据拿出来比较，发现后者的性能大概是前者的3倍左右，所以这性能均衡对系统性能也有很重要的意义。
上面和二位微软和浪潮ERP方面的技术专家谈了一下我们ERP压力测试中所遇到的一些问题。这对我们能解读测试数据背后的含义有很大的帮助，相信对很多使用ERP的企业有些启发。
问：测试过程中还有些其它的概念。比如说think time。这think time在是什么样概念。在测试中和实际操作中有什么不一样？
张：think time直译过来就是思考的时间。在运行应用程序的时候。中间有很多的操作在里边。Think time就是指多次操作中间的时间间隔。比方说去点某些菜单，或者说键盘输入某些数据。这中间可能有一个鼠标移动的时间，或者对录入的语句进行校验，人工校验后才选择保存，这些操作所消耗的时间就有可能是think time。
Think time在性能测试过程是可以选择完全略掉，也就是Think time为零。这样一种情况下实际上模仿的是应用程序和在有压力的情况下它中间是没思考时间的。没有Think time，只有连续不断的进行程序和数据库操作。这样的情况下对后台系统的压力是非常大的。要是真正的去模拟实际的ERP操作场景呢，一般来讲我的们的Think time需要去设上一个尽可能贴近实际的思考时间去模拟这个实际场景，这主要是压力测试中think time的概念。
问：刚才张伟杰主要对我们这次ERP测试涉及的一些基本概念做澄清。这对众多网友解读ERP测试报告有很大的帮助。张伟杰提到就是并发数和真实在线的用户数这是两个相对区别的概念。实际系统的在线人数他可能只是维持了一个用户登录的一个汇话。但是这个用户呢他其实什么操作都没有。比如说他这个时候他在接电话，实际上对后台系统是没有任何压力的，就是因为这个信息点的概念和同时在线的人数可能还有点区别，就是说不可能所有的信息点同时的都在使用。比如网站、论坛这类的并发数和在线人数的差别可能是数量级的。而ERP的系统在线人数是约等于并发数的，不等同就是信息点总数。对于ERP系统来说多少个信息点会产生一个什么数量的并发数，我不知道高工那边有没有一个可以大致衡量的标准。比如说假定我们经过测试。我们4路双核的系统做的物流的测试能够接纳200个并发。那么在真实的环境里。你们这样的系统大概能支持多少个这样的信息点。
高工：这块是有的。客户在使用浪潮ERP软件的过程中，企业规模不同，信息点数也是不一样的。在实际使用过程中，企业规模在30到100个信息点之间的，并发数的比例大概35%-40%。随着用户信息点的增加，并发用户数会有一定比例的下降。因为点数多了以后，他不可能都在使用。信息点数越多，他并发用户数的比例就会有一点下降。举例说企业有200个信息点可能同时在线的数在35%以下了，这就是在实际企业运用中这么一个经验值吧。
问：也就是说实际并发和它支持的信息点数大概是1：3这么个概念。那么我们实测出来大概能支持200个并发的话就相当于实际支撑的在线人数可以达到600人左右。
高：是的，600个信息点也是一个很大的应用了。中小型企业里头一般很少会达到600个信息点的，这已经算是规模比较庞大的企业了。
PConline：从你们实际应用的客户来看。最大规模的用户大概有多少个信息点。
高工：最大规模的也就是2、300个左右。
问：也就是说实际上你们的ERP软件除了这次的压力测试。以前从来没有承受过这么大的并发量？
高工：的确是的，因为本身浪潮PS-ERP是对应中小企业的市场来开发。它这个并发数应该不会太高。
问：关于测试当中有一个基本的概念。高工这边还有没有需要补充的。
高工：我补充下刚才张工提到的think time，Think time本身是测试软件里的一个名词。它这个在ERP系统中是怎么体现的呢。我们可以这么理解，在这个实际ERP操作里拿出一张单据来讲，它这个think time可能就在录入的过程中有一些人工去校验的时间，包括人工去核对的那个时间。因为核对正确以后我们才会保存，这个单据才算制单完成了。这是一个整个过程，像人工校验和核对的这个时间就可以把它在ERP这个系统称之为think time的一个时间。那按照一般经验来讲一个熟练的员工他完成一张单据的录入，比如说一张入库单或者一张销售出库单，可能最少的可能也要花个两三分钟吧。我们测试的时间其实就是机器系统的平均响应时间。这其实是远远低于实际中的操作时间的。
问：我们接下来就测试当中发现的一些问题咨询下二位。这些问题可能相对的比较具体一点，比如说说在测试帐务模块中的科目余额查询。开始我们理解是一个查询功能，但是实际测试的情况来看这个模块响应的时间非常的长，甚至超过有十分钟的。那么后来我们是简单查阅了脚本。从功能表达上感觉科目余额查询更像一个报表功能吧。就因为脚本设置中我们大概设置查询的期间是2007-1-1至2007-8-31这一个时间段，科目数目大概有10来个科目。我觉得这样功能他更像一个生成报表的功能，而不是一个简单查询的功能。
高：测试中对这模块设置的并发数多了一些，因为实际操作中不可能达不到这么多并发数。科目查询在这个过程中对数据进行了一个复杂计算、汇总、统计、分析然后得出这么一个结果（显示报表）来。另外我们准备的数据是在这个企业好几年累计下来的一个数据。虽然查的是1-8月份的，但是实实在在的数据量摆在那里，查询的时间长度也占了一定的时间。这几方面都会造成这模块的响应时间比较长。在企业实际使用的时候，它不会像我们这样去查询的。不会跨越这么长的时间段然后同时查那么多的科目。查的话可能只是查某一期间、某一科目的数据，那样的响应时间不会很长。
张：我补充一下，关于查询这块比较缓慢的问题。脚本场景中设置的科目查询，无论是时间上还是业务范围上，跨度都很大的。测试中查询的是大概有半年多的数据，各个类别科目都进行查询。这是和实际的区别很大。另一方面从硬件角度来看，比如服务器，如果内存比较小的话，在做大的数据量查询的时候没有办法把非常大的数据量一次性放到系统的内存里，还会保留一部分在磁盘上。这时候进行查询的话，它需要频繁对磁盘去做一些IO读写的操作。大家都知道，内存的速度是要远远大于你磁盘IO的速度。所以说这时候的瓶径很大原因在磁盘上边。而现实中的操作里，查询数据量一旦小了下来，比如说只查询一个月的。这时即便系统的内存有些小也可以一次性的将的数据都放到内存里执行，这样查询速度也是非常快的。
