项目管理手记(六) DRP项目因为系统性能“四进宫”，何解？

项目管理手记(六) DRP项目因为系统性能“四进宫”，何解？

 

                                 童继龙/[e-mail]

 

已经有三个月时间没有到温州了，正好这次有机会出差到温州，可以和温州的一班老朋友们好好聚聚，同时也开怀畅饮，边喝边聊了，因为大家一直都不缺乏深入交流的话题。这不，人还没有到温州，“温州IT主管联盟”的“老大”—老胡就抛了一个案例，说是要给大家看看，再一起帮着参详参详的：

 

伴随着DRP项目的推进，软件方的顾问也逐渐撤出了，系统的运营自然也就成了企业IT部门的任务，而随着DRP系统的不断深入应用，其它信息系统的不断上线，企业信息化程度的也越来越深，企业对于软件应用性能的要求也就越来越高，就需要对IT系统进行升级扩容等全方位的改进。从技术角度来看，在升级改造过程中，比起全新信息化建设的困难度，实在是有过之而无不及。

这类的因系统性能问题而升级改造的，不成功的案例多于成功的案例。让我们来看一下这个因系统变慢而"四进宫"的案例。

原由：系统的响应时间慢，就是系统的升级的主要原因!

软件平台：

操作系统： Microsoft 2000 server

数据库： Microsoft SQL server

应用软件： 行业内成熟的DRP软件, 单机运行

硬件平台：

服务器：DELL (2个CPU，2GB的内存，和18GB的硬盘2个做镜像)

磁盘阵列：DELL的220S SCSI盘阵（使用18GB的硬盘14个做RAID-5，共250GB)

经过两年的上线使用后，算是成功上线使用，但是开始有用户反映这个系统的响应时间越来越慢，希望信息中心可以提升系统的性能。

信息中心和几个供应商的会诊后，确认是硬件指标太低，造成性能太慢。

硬件慢，简单！只要有银子就可以解决。销售商介绍更高规格的硬件设备，于是把原来的设备转成其他的应用上，这个主要核心系统全部采购更新的高性能指标设备。

第一次升级方案：购买高性能指标的服务器

提高服务器的性能指标：

换服务器，把CPU 2个变4个，主频1.8变成3.6, 内存2GB变4GB

换存储设备，SCSI盘阵太慢，换成2Gb Fibre光纤盘阵，加上2Gb的光纤交换机，采用最新的SAN存储结构技术，采用DELL推荐的中小企业用的盘阵AX150 (双控、500GB SATA 硬盘7个)共3.5TB的容量，连数据备份一并解决。真划算，价格也不贵，总价在30万以内，在原来的预算内，有银子真的很好用！

兴高采烈的迎接全新设备的，好像娶媳妇一样，信息中心上上下忙了大半个月，从培训、安装硬件软件、倒数据、系统测试、系统切换，连续加班好几天。总算把它侍候好了。

系统上线了，和供货商一起聚聚，喝喝小酒，联络感情，以后好配合！

三个月过去了，业务端反映，系统速度好像没有什么改善，甚至还慢了。财务部门反映每个月的结算，速度和以前差不多。

 

第二次升级方案：修改软件

硬件已经提升了，有问题可能就是软件问题，要软件商进行二次开发，修改软件。软件公司因为慢的问题，收不到开发费用，效果也就有限了。这又加班好几个月的时间，改善不明显。

软件公司找了一个高人，检测后，确定还是硬件问题? 问题又推到存储上！

 

第三次升级方案：升级盘阵上的Firmware

服务器的工程师进行了盘阵上的操作系统版本和补丁，不见效果，和存储厂商的资深系统工程师，再继续找问题。最后换了一个高级技术经理，一看，你这个AX150盘阵规格太低，只适合做备份，不适合做OLTP应用，应该使用更高档的全光纤盘阵，应该就没有问题。

 

第四次升级方案：更换4Gb的光纤盘阵

现在是2007年，主流产品都是4Gb的光纤，于是更换更高指标的存储设备CX3-20，带宽是4个4Gb，共16Gb的带宽，盘阵内存是4GB，硬盘使用300GB的4Gb纯光纤硬盘8个，服务器上加两片4Gb的HBA卡，更换4Gb的光纤交换机。服务器的内存增加到8GB.

大半年过去了，听说系统的缓慢又出现了！

心疼吗？白花花的银子这样来花！那么在这个升级的案例中，问题出在哪里了？

 

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

仔细分析上面的案例，其实没有给出一个相对客户的数据，说系统慢，是在操作系统、数据库、多少的服务器端带宽、多少个并发用户数、客户端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系统中，也仅仅是一两家而已。