二、案例分析

    上述的问题，经老胡一抛出来，就引起了大家的热烈讨论，因为这类的问题在各个企业都曾经碰到过，就算目前暂时没有碰到的，以后也会碰到，总之，这是任何一个企业都绕不过去的问题。正好当时手上上有事情，没有怎么深入思考这个问题，回过头有时间静下心来的时候，就觉的这个问题值得好好研究。 

    仔细分析上面的案例，其实没有给出一个相对客户的数据，说系统慢，是在操作系统、数据库、多少的服务器端带宽、多少个并发用户数、客户端PC配置等情况都未知而由业务部门的使用人员发出的呼声。 

    在这里，我觉的其实是可以根据用户的操作类型来区别一下的，系统性能应该包括两部分： 

1、 OLTP(On-Line Transaction Processing，联机事务处理)操作：用户操作单据时，包括新增、修改、删除操作，类似的这种事务性操作应该要求响应比较及时，用户可忍受的等待时间应该是在5秒钟以内。 

2、 OLAP（On-Line Analytical Processing，联机分析处理）操作：而在于进行查询与统计操作的时候，由于用户对于查询的数据不同，其心理预期也是不同的，预期的时间可以从5秒钟到15分钟不等，毕竟查询的数据量不一样，所需要的结果返回时间也是不一样的，这一点用户应该是可以理解的。 

    那么，我们要分析的问题主要就在事务性操作上，要求操作响应时间在5秒钟以内，这应该是我们的一个最基本的目标。也就是说，我们目前要分析的主要就是OLTP的性能。 

    由于OLTP性能会涉及到非常多的因素，包括服务器、DRP软件系统、网络状况、客户端PC机配置、数据库、用户等，针对这些情况，我们用下面的因果图进行分析：

    针对上述的因果图，我们可以根据上述原因进行逐一分析与排查，并制定出具体的应对方案。

1、 DRP系统：DRP系统本身的原因，也是系统速度慢的根源所在，毕竟所有的硬件及网络设备都是为DRP系统服务的。 

    a) 从软件架构不合理上来考虑，在前面的一篇文章中，我有针对DRP系统的架构进行讨论的，有兴趣的朋友可以参考(http://blog.csdn.net/Drate/archive/2007/07/17/1694698.aspx)。 

    b) 而对于大量使用数据感知控件，这应该是程序员的错，因为在开发小应用系统的时候，如使用DBGRID这样的控件，一次显示整个数据表的内容，如果数据条目在100--1000条，可能速度不会有太明显的差异，但如果数据条目是在1000条与100万条之间比较的话，那肯定就不是同一个层面上的了，所以进行数据显示的话，直接与数据源关联，有可能会引起资源耗尽的情况还没有能够显示出你所请示的内容。 

    c) 习惯性全表数据显示，这也是软件开发者在进行开发时没有注意的问题，因为性能问题都是在有了大数据量的时候才会显示出来的，开发期间由没有大数据量，开发人员也意识不到，所以进行提供用户查询功能的时候，基本上不会用限定条件，或者也不进行数据分页显示，导致数据库服务器的数据请求量直线上升。

2、 网络：网络与系统的稳定性是直接相关的，特别是目前的DRP系统中，采用的都是数据大集中的方式，所有的数据请求、数据处理都是要通过网络来完成的。网络的问题可以归结为以下几个方面。 

    a) 服务端的带宽，目前一般有ADSL、2M、10M、100M的光纤可以使用，系统数据慢，可以通过测试看服务器端的带宽是否足够。 

    b) 电信与网通的问题：这是中国特色的问题，由于网通主要在北方，电信在南方，所以终端的线路情况各不一样，特别是进行跨网络访问的时候，速度会是奇慢，而且网络会经常莫名其妙的断开，现在很多企业在机房里各拉一条网通与电信的光纤就是这个原因。 

    c) VPN、防火墙问题，为了增加网络的安全性，VPN接入是目前DRP系统常用的一种方式，防火墙也是必不可少的，可是如果VPN或防火墙的性能不够的话，也将会使网络阻塞严重，系统自然也就慢了。 

    d) 客户端带宽：客户端带宽应该在目前来说，问题不会太大，因为现在ADSL的普及，很难再找到使用MODEM拔号上网的了，就算是现在的无线网络，其速度也远远要比MODEM拔号上网要快的多。 

    e) 网络设计不合理：这个问题是会是一个非常隐秘的问题，如：由于企业的网络管理员水平有限，没有对网络内的计算机进行分网段管理，容易出现“网络风暴”，导致交换机进行频繁的垃圾数据交换，交换机也是经常性死机，自然系统的速度会下降了。又如网络内存在病毒或者是木马，在网络内发送大量数据包，或者甚至是DoS(拒绝服务攻击)。

3、 服务器：一般包括以下几种类型的服务器，一是数据库服务器，二是指应用服务器，三是存储服务器，在这里我们不进行特指。 

    a) 服务器总线IO：在服务器领域，数据是需要进行密集交换的，而IO总线的频率基本上决定了一台服务器的性能，所以，为什么不同服务器之间的CPU、内存可能都差不多，但价格相差很多？同样性能也有很大差异呢？关键就是在于服务器的总线IO能力了。 

    b) CPU性能：目前的PC服务器，一般都是能够加载多颗CPU的，是选2颗还是4颗或者是8颗，那就是要看应用的情况了，一般来说，在CPU的负载在80%以下是比较正常的，因为如果有一个峰值的话，CPU的负载就马上会到100%以上的。 

    c) 内存不足：内存也是和CPU一样，可以在服务器上进行扩展，根据需要进行配置，这个问题也比较明显。 

    d) 磁盘IO问题：磁盘IO，这里有可能是用磁盘阵列柜，也有可能是光纤存储，如果在用阵列柜的话，就要看一下是否是这里的问题了。 

    e) 服务器间网络带宽问题：由于存在着数据库服务器、应用服务器、存储服务器，这几个服务器之间的带宽是否能够在1000M？或者是直接用光线网络进行数据传输？这也是根据应用情况进行考量的。

4、 数据库 

    a) 数据库系统配置不合理：DBA在这里就起到非常大的作用了，特别是像Oracle这样的大型数据库，一个好的DBA，可以将数据库系统的配置与软件系统达到最优化组合，性能的提升也是非常明显的，而如果是一个菜鸟来做的话，估计只会按照安装的默认配置来运行，系统性能相差的就远的去了。 

    b) 数据库索引及优化：数据库索引与优化，如果DRP软件商有对数据库非常熟悉的软件架构师，会对数据库的索引进行优化，以提高系统的效率，但说实话，目前更多的软件商将精力放在了前端的界面展现上，而不是数据库的“内功”修炼上。 

    c) 数据冗余：合理的数据冗余可以增强系统的性能，这是谁都知道的，但有的系统却是过滥，将数据库设计的过分冗余了，导致数据库成了吃硬盘的“杀手”，数据库一直不停地高速膨胀，系统性能也就直线下降了。 

    d) 存储过程与触发器：存储过程与触发器，这应该是属于业务逻辑层来干的事情，如果一个好的系统，我认为应该是不在数据库层面来执行业务逻辑的，所以，一直比较抵触这两个，特别是触发器。

5、 客户端PC配置太低：比较容易理解，386的机器跑WINDOWS XP，老牛拉破车吧。

6、 用户 

    a) 用户心理预期较高：由于用户可能之前有用过类似的系统，由于数据量较小，或者之前用的是小系统，有一个习惯的问题；或者就是一个心理预期，认为一个新系统的话总会有算改进的，所以就把新系统想的很美好，结果实际上不是这么一回事的时候，自然就有落差了。 

    b) 并发用户数量：并发用户在10个与100个的时候，系统的速度，对于硬件、网络设备的要求肯定是不一样的，因此，在做评估的时候也要将这个因素考虑进来。 

    c) 用户无意义操作：用户经常性无意识地刷新数据就会对系统的性能造成影响，但用户可能并没有意识到，因此，这一点需要在用户培训中提醒进行归避。 

    针对上述列举的问题，需要做出一个详细的性能测试表格，对以上各项数据进行测试，找到问题的瓶颈在哪里，并针对问题的瓶颈，有规划性、针对性地部署升级计划。同时需要IT部门定期对上述性能进行评估，以便IT部门能够及时发现问题，而非在业务部门怨声载道的时候再来匆忙解决问题。 

    除上述的应对措施之外，还需要注意一点，就是将OLTP与OLAP应用分别部署在两台服务器上，甚至有必要的话使用两条不同的光纤接入。当然，这就对DRP系统的架构提出一个新的要求，即对用户无关性：用户感觉不到后台是进行了数据库分离的，OLTP、OLAP操作都在同一个软件界面中完成，并不需要进行数据切换和数据合并等操作的，这样就能够在不降低用户对系统的使用期望而达到提升性能的目的。能够实现该架构的，目前笔者接触的服装行业DRP系统中，也仅仅是一两家而已。