ERP会堵住网络吗?

在计划和部署企业ERP应用时，人们往往很注意系统本身，而忽视了网络这一重要因素。企业IT部门花费大量的时间用于配置服务器并且计算它们能够支持多少用户，而很注意计划客户端的软件分发。企业的部门首脑也很注意如何对员工进行训练，以便使他们能够使用这些新应用。然而他们都忽视了一个最基本的因素：网络。他们都根据以前部署其它应用的经验，简单地假设了企业网络能够像处理所有其它的应用一样处理新的ERP应用，但事实上，这种假设却是错误的。

ERP结构
ERP应用绝大多数都部署在高度分散的分布式环境中。虽然ERP服务器可能是中央化的，但客户端一般都是部署在整个企业的各个角落。
一般而言，在ERP系统中服务器和客户端之间有三个功能领域是分布式的。第一就是数据库组件，它存储所有来自客户端和传输到客户端的数据。第二当然就是客户端，由它进行初始的数据输入、发送请求以及显示满足这些请求的信息等。第三个就是在客户端和服务器之间充当中介作用的应用组件。
由于ERP实施都是根据用户的具体需求进行定制的，因此这些组件物理上位于何处以及如何相互作用也是差别很大的。但最通常的两种实现结构是两层结构和三层结构。
●两层结构
在一个典型的两层ERP结构中，服务器处理与应用和数据库相关的请求。客户端负责显示数据以及将用户输入的数据传送给服务器。虽然在实际的ERP系统中可能会有多个服务器和客户端跨越多种局域网和广域网链路，但它们的基本处理过程都是相同的。图1显示了最简单的两层ERP实现的结构示意图：

图1：两层ERP结构

●三层客户／服务器结构
在三层结构中，数据库功能和应用功能是分离的，较大规模的ERP部署普遍采用的就是这种结构。在这种方案中，要想满足客户端请求需要两个或更多的网络连接。在使用时最初由客户端建立与应用服务器的通信，应用服务器然后创建与数据库服务器的连接。图2显示了这种实现的三层式结构示意图：

图2：三层ERP结构

业务流量
从ERP实现的结构上，似乎看不出它与其它的分布式应用有多大区别，无非也就是服务器与客户端通信以及服务器与其它服务器通信罢了。如果单纯从业务流的方式上讲，ERP应用与其它的分布式应用的确没有太多的差别。然而在ERP应用中，客户端和服务器之间要持续进行大量的业务流，而ERP应用对性能（系统的应答时间、延迟等）要求又非常高。在一个高速低延迟的链路上，性能可能不会成为一个问题。事实上，这就是为什么性能问题直到ERP应用实施以后才被人们注意到的原因。因为在最初的开发和系统的测试期间，客户端和服务器一般都在放在孤立的网络或一个单个的子网中完成的。在这种环境中，端用户可能从来不会遇到性能问题。但是当在真实的企业网络中部署ERP应用时，性能问题便会出现，因为企业网络中数据交换很多。
由于绝大多数ERP应用都是针对每一个具体的用户而定制的，因此每个ERP应用的实现方式可能会各不相同。为了创建测试ERP应用业务流的的脚本，美国GanymedeSoftware公司对各种ERP应用进行了广泛的分析，该公司测试了在ERP应用中使用SMTP协议发送电子邮件信息这样一种典型的网络交换方式，发现在网络上的，包括由客户端和服务器任何一方发起的数据传输的量是相当大的。
为什么会在网络上发生那么多的数据交换？原因就在于ERP应用和个别的处理操作本身也是非常复杂的。一个单个的业务，如增加库存条目，可能就需要端用户填写几个信息表格。当每一个表格被完成以后，数据就要在网络上来回传输。每一个这样的表格都有好几项内容必须填写。在有的ERP应用中，甚至将光标从一个项目跳到另一个项目时也会导致数据在客户端和服务器之间进行传输。
事实上，在两层和三层环境中，通信流量是有区别的。虽然发送的总数量可能不会发生太大的变化，但通信方式将会发生大的变化。在三层式环境中，服务器－服务器链路经常要承担主要的通信流量，而不是由客户端－服务器链路来承担。因此三层式环境会给ERP应用带来性能管理方面的问题，而且当端用户遇到应用性能方面的问题时，要确定性能故障发生在哪一个特定的服务器或网络连接也是一件困难的工作。

ERP对网络性能的影响

本部分的测试结果是我们使用GanymedeSoftware公司的Chariot软件和ShunraSoftware公司的Cloud软件产生的。Chariot被用来模拟与一个典型的ERP业务相关的各种网络流量，Cloud被用来模拟几种不同的WAN环境。在下面的每一个测试中，我们使用Chariot来模拟在上表中列出的“增加用户数量”这一业务流程。这个流程由客户端和服务器之间的242个发送操作组成。为了确保统计的有效性，每个测试都重复进行10次，最后取平均值。
严格地讲，系统处理一项业务所需的总时间包括客户端输入数据的时间、服务器处理这些数据的时间以及网络传输时间。但客户端输入数据的时间并不是一个特别影响ERP性能的因素，因此这里我们将测试的重点放在网络的应答时间上。
下面是具体的测试结果：
●局域网（LAN）性能：在第一个测试中，我们使用Chariot来模拟在100Mbps的LAN链路上增加用户数量时对网络性能的影响。在这次测试中网络只达到了0．085Mbps的输出，5微秒的理论应答时间变成了6秒。显然如果想准确的预测这一类应用的性能还需要综合考虑多种因素，网络性能只是一个方面。
●广域网性能（T1线路）：紧接着，我们使用Cloud来模拟客户端和服务器在T1链路处理以上操作的情形。结果系统的应答时间已经从LAN上的6．2秒跳到了T1线路上的10．5秒。初一看这个结果也不算太令人失望。但是别忘了在这次测试中，我们假设了用户完全拥有一个“空”T1线路，没有其它的通信和其它的用户。在现实生活中，线路是一种共享的资源，每一个用户都只能得到总带宽的一小部分。因此10．5秒的应答时间只具有理论上的意义，在现实生活中是很难实现的。
●广域网性能（56Kbps）：第三次测试是模拟在56Kbps的链路的情形，这里再次假设了链路上没有其它的通信，用户占用全部资源。结果发现每个操作的网络应答时间从6．2秒上升到了接近40秒。这个结果也许与当用户共享T1线路时网络的实际应答时间很相似。
●广域网性能（28．8Kbps）：最后我们模拟了28．8Kbps的拨号线路，结果最大应答时间已经超过了80秒。一个使用繁忙的T1线路的用户在访问ERP应用时可能会出现类似的结果。
上面我们介绍了测试了在企业LAN、T1线路、56K线和28．8K线路上使用ERP时对网络性能的影响。这几种线路应该包括了企业使用ERP时可能会用到的链路情况，因此它们是很有代表意义的。需要说明的是，我们都假设了测试是在“空”的广域网链路上进行的。在真正的网络中有许多不利因素会发生，如拥塞、包丢失、碎片、比特错误等。所有这些都会影响上面测试的结果。

结论
网络性能是许多企业在部署ERP应用前经常忽视的问题。为了能够充分预测到部署ERP应用以后的网络效果如何，在部署ERP应用前应该认真考虑以下几个问题：
1．ERP应用与任何其它的网络应用都是不同的，不能用部署其它应用的方法来考虑ERP应用。
2．每一个ERP部署都是不同的。ERP的应用模块是定制的，系统结构和计算资源的分发要根据用户的具体应用环境确定。
3．提前测试你的网络以了解这些应用是如何运行的，以及它们将对现有的应用产生什么样的影响，特别是要注意在WAN链路和负载较重的LAN上使用ERP时的情形。
4．计算机资源的物理位置可能会对ERP应用的运行效果产生重要的影响，在三层式环境中尤其是这样。