引言 网站建设的发展使得保证支持)*+站点的,- 基础结构能够为访问公司的信息、产品和服务提供可用、可扩展、快速且高效的途径成为了关键任务。 规划网站时必须确保网络及其组件能够处理将来访问站点的用户数量。容量规划是一个长期过程。它需要不断监视服务器的使用情况，以确保有足够的资源来保证客户的访问。随着时间的推移，大多数规划都会碰到用户数量和访问的内容总量大大增加的情况。当高峰用户数量访问网络上的应用程序和服务时，容量规划对于确保系统能够充分运行至关重要。因此必须充分规划网站，使其能够瞒足最大数量用户同时访问网站的请求，并在此基础上确保网络的硬件和软件容量能够满足预期需求。本论文介绍容量规划所涉及的有关问题，以及如何规划网络的容量要求。 1、容量规划的简介 任何网站的目标都是向用户提供优质的服务。当用户遇到反应速度慢、超时和错误、链接断开等问题时，他们会失去耐心，并转向其他网站去查找所需内容。要防止这一点，就必须提供一个不但能处理常规需求水平，而且能处理高峰需求水平甚至更高水平的基础结构。容量规划让我们能够计算满足用户需求所需的硬件要求。这类计算可以使我们识别在网络设计中造成性能降低和导致服务质量降低的瓶颈，然后我们可以修改设计或根据需要做出更改来解决瓶颈问题。 网站容量是由用户数量、服务器容量、硬件和软件配置、以及网站内容来确定。容量规划可被表述为一个简单等式：支持用户数量. 硬件容量/ 硬件的人均用户负载在这个等式中，支持用户数量指同时访问的用户数量，硬件容量指服务器和网络容量，硬件的人均用户负载是指访问用户的人均硬件开销。容量规划通常基于两个概念： (1)降低每位用户给硬件增加的负载，这可以通过对网站内容进行规划、程序设计和配置可以更加有效地利用现有资源。 (2)配置网站的基础结构以增加硬件容量，方式有硬件扩展（增加服务器数量）或升级（将现有服务器升级）。 如果网站内容复杂性提高了，那么就增加了人均用户的硬件负载，但仍然要保持可支持的用户数量，那么就必须增加硬件容量。这可以通过扩展和升级两种方法解决；如果希望能够支持更多的用户，就需要增加硬件容量或降低硬件的人均用户负载。 通过统计访问网站的用户数量并测量每位用户对服务器的需求，然后对支持当前和将来使用水平的计算资源（CPU、RAM、磁盘空间和网络带宽）进行计算，这样可以确定网站的容量水平。 2、容量规划过程中应考虑的几个因素 容量规划所涉及的几个因素： 2.1 通信 当浏览器向WEB 服务器发出请求时，浏览器首先会与服务器建立一个传输控制协议（TCP）连接。然后浏览器通过该连接发出请求，服务器则相应请求发出页面，这种输入请求与输出相应的互换被称为通信。通信不可完全预测。比如，有很多站点可能经历过工作日开始及结束时的活动高峰，而中间那段时间的活动水平则较低。另外，每天的高峰规模也会有所不同。通信量与支持通信所需的网络带宽之间也存在直接的联系。站点访问者越多，服务器提供的页面就越多，从而就要求更多的网络带宽。 2.2性能 WEB应用程序的性能对于确定网站的容量至关重要。确定WEB应用程序的容量和性能的唯一方法是进行测试。常用的测试工具有：公用程序WEB容量分析工具（WCAT）和WEB应用程序STRESS 工具（WAST)。 2.3可用性 可用性是规划网络容量要求时需要考虑的重要因素。首先必须确定要获得什么类型的可用性。争取达到多高的程度？这取决于公司打算投入多少财力来保证网络始终能够满足高峰容量需求？必须确定的一点是因网站不可用而引起的问题是否能抵消为此联机状态所支付的费用。 2.4伸缩性 准备对网站进行升级以提高其可用性、增加同时用户数量、或减少网站等待时间加快响应时间时，网站的伸缩性是需要考虑的首要因素。网站的伸缩性与可用性机密相连。网站升级不应该产生无计划或不必要的停机时间。 3.规划网络容量步骤： 3.1确定站点的用途和类型 开始规划站点的容量需求之前，您必须确定站点的用途，以及要创建什么类型的站点。例如，要创建一个事务处理站点，以允许用户检索并存储信息，一般是在一个数据库中。事务处理站点涉及可靠性和安全性要求，而其他类型的站点则没有这样的要求。除确定站点类型之外，必须确定站点是否要支持某些形式的动态内容。动态内容有很多形式，而且各种不同的,INTERNET 及数据库技术都提供动态内容，如SQL、ASP或CGI。简单来说，动态内容涉及到WEB 服务器与数据库联系、检索数据、将数据格式化、然后作为)WEB页面发送到用户的浏览器上。例如，如果一位用户要查看某个特定产品的信息，服务器就会联系SQL Server数据库以检索该产品说明、照片、价格信息，以及该产品是否还有库存。检索结果会以常规的HTML页面显示在用户的浏览器上，就像一个静态)WEB页面，但它却是服务器在用户发了请求时在运行过程当中创建中。使用动态内容的站点比静态站点需要的处理容量要多得多。 3.2确定用户基数 下一步是计算)WEB站点的容量，以确定同时使用站点的用户数量。这个数字通常有两个主要来源：市场分析和系统分析。 如果站点还未建立或发布，站点所有者和操作人员就可能需要借助市场分析报告来预测站点发布初期及以后的预期通信量。如果站点已经建立且已在运行，分析WEB服务器的日志文件，以了解站点在不同时间的点击数以及可以表明站点内容受欢迎程度是否增加的所有使用趋势。计算站点当前支持的用户数量时，要根据高峰使用来计算，而不是根据典型使用或平均使用。 3.3确定硬件需求 通过预测站点某一段时间的访问者数量或统计一段时间的实际访问者数量并将该数据与硬件容量相比较,您可以确定站点的硬件需求。 3.3.1 CPU需求 WEB应用程序受处理器约束。多个线程试图执行相同的关键部分或访问相同资源可导致资源争夺问题，从而导致频繁的环境转换并在吞吐量很低的时候也使CPU处于忙碌状态。如果多数线程阻塞，如等待数据库时，就还有可能出现CPU利用很低，吞吐量也很低的情况。 可以通过两个基本方式获得所需处理能力：向每台服务器添加更多的处理器，或者添加服务器。与添加服务器相比，向现有服务器添加处理器的成本更低（也更更简单）。但对于多数应用程序来说，添加处理器到一定程度时就不起作用了。另外，操作系统支持的处理器数量也有限。 添加服务器可以将群集线性扩展到您所需要的大小。（线性扩展就是说两台服务器可处理两倍于一台服务器可处理的负载，三台服务器可处理三倍的负载，九台服务器呆处理九倍的负载，以此类推。） 3.3.2内存需求 RAM存取（约10毫微秒）大约比磁盘存取（约10毫秒）快一百万倍，所以每次将一个页面交换到内存中时，就是在降低应用程序的速度。添加充足的RAM对任何系统来说都是获得最佳性能最好、最经济的办法。而且您可以通过检查分页计数器（应用程序一旦开始运行，分页活动就应当很少）来保证应用程序有足够内存。 3.3.3存储需求 随着企业网络不断增长. 网络存储解决方案正在日渐成为人们的选择。每个公司在选择数据存储的介质和方法时都有不同的考虑。有些公司受制于成本，而有些公司则着重考虑性能。在评估存储需求时，需要将可提供高可用性的存储系统的成本与可能出现的数据损失、生产率、商业等因素相比较。制定存储管理策略之前，应考虑下列需求： ·对公司来说成本最合算的技术 ·可以满足网络发展需求的充足的存储容量 ·对小时访问重要数据的需求 ·数据存储的安全环境 在寻找成本最合算的解决方案时，需要在购买并维护软硬件的成本和出现灾难性数据损失的后果之间进行权衡。成本包括下列费用： ·硬件方面的初期投入，如磁带和磁盘驱动器、电源供应、控制器 ·相关介质，如磁带和光盘 ·软件，如存储管理工具和备份工具 ·当前的软硬件维护费用 ·人员配备 ·如何使用新技术方面的培训 ·脱站存储设备 将上述费用与下列费用做比较： ·更换文件服务器、邮件服务器或打印服务器的费用 ·更换运行SQL Server或系统管理服务器（Systems Management Server）的费用 · 更换运行路由和远程访问服务（Routing and Romote Access Server ,RRAS）、SNA Server、Proxy Server或Novell Net Ware的费用. ·为不同部门的人员更换工作站的费用 ·更换个别计算机组件如硬盘或网络卡使用 选择存储系统时需要考虑的另一个重要因素是数据恢复的速度。如果服务上的数据丢失，多快能够恢复数据？在故障开始严重影响到公司业务之前，您能够承担的服务器（或整个网络）故障时间有多长？ 存储技术发展迅速，所以在作出采购决定之前，最好对各种类型的相关优点都有所了解。要使用的存储系统应该具备比备份关键数据所需容量还要高的容量。而且这个存储系统还应该能够在备份和恢复操作过程中执行错误检测和更正。 3.3.4数据服务器和磁盘需求 数据库是一个潜在的瓶颈，一旦有问题会很难修复。读E 写实时数据必须有一份完全相同的数据副本，所以增加数据库容量更有难度。有时瓶颈可能在数据库服务器上，有时又可能在磁盘阵列中。 如果问题在服务器的CPU 容量方面，则可通过添加CPU来解决。数据库应用程序如SQL SERVER可充分利用新增处理器；如果磁盘是瓶颈，则可采用更快的磁盘阵列。若数据库应用程序可利用高级缓存技术，添加RAM也会有所帮助。 另外一个选择是将数据库分配到多个服务器上。首先可将目录数据库放到一台服务器或一组服务器上。因为目录通常是只读的，复制数据会很安全。其次可以将经常阅读的数据如客户信息进行分段或将读E 写数据分段，这样可加快数据库的访问速度。 3.4确定网络带宽 一旦确定了特定时间要支持的用户数量，就有了网络连接带宽的下限，能够支持常规负载和使用尖峰。但站点类型在很大程度上影响到这个问题。例如，如果网站在很大程度上是基于用户或完全基于用户，或者站点只是在内联网上或是内联网结合外联网，可以估算最大尖峰时刻的网络带宽。硬件联网后可能存在若干潜在瓶颈。首先，对于您所发送的所有数据来说，网络与Internet的连接可能不够快。如果应用程序很受欢迎，您就可能需要速度更快的连接或使用冗余连接。冗余连接也可以增加站点的可靠性和可用性。通过减少发送的数据量，特别是图形、声音、和视频，可以降低对带宽的需求，从而防止瓶颈发生。如果您的防火墙不能够快速处理通信量，也会成为瓶颈。需要注意的一点是以太网络不能以接近其理论容量的水平运行，因为这会产生很多冲突（两个发送机试图同时发送）。发生冲突时，两个发送机在重新发送之前都必须等待一段时间。有些冲突无法避免，但随着网络趋于饱和，冲突会迅速增加，这样您就几乎没有有效带宽了。 使用交换机（而不是使用集线器）将网络互连可大大减少冲突。交换机直接连接两个端口，而不是将通信传播到所有端口，所以多对端口可以通信而不发生冲突。与集线器相比，交换机则是不错的选择。 3.5查找潜在瓶颈问题 通常在网络出现拥塞之前，尽可能提前查找那些潜在的隐蔽的瓶颈问题，找出那些可能最先出现问题的地方。查找潜在瓶颈可遵循下列步骤： (1)画出标示所有进入站点路径的方框图，包括：如到FTP下载站点的链接、其他URL等。 (2)确定容纳各个功能组件（数据库、邮件、FPT等等）的机器是什么。 (3)画出站点网络模型和到它的环境的连接。确定吞吐量，确定链接的速度。 (4)为每个页面创建一个回答下列问题的用户配置文件： · 用户停留在该页面上的时间有多长？ · 哪些数据传送到该页面上或该页面传送了哪些数据？ · 该页面生成多少数据库活动（或其他活动）？ · 每个页面上有什么对象？这些对象对系统的友善程度有多高？（即这些对象加在系统资源上的负载有多重？如果这些对象出现问题，有没有影响到其他对象或应用程序？） (5)定哪些是客户端对象，哪些是服务器端对象。 3.6更新WEB站点 在确定了站点每台服务器可支持的用户数量以后，可以考虑站点的扩展问题，以支持更多用户或向现有用户提供更好的服务。 下列基本策略可用来更新站点： · 提高每台服务器可支持的用户数量 · 提高站点可支持的同时用户的数量 · 缩短站点的延迟时间，以提高响应速度 您可以选用下列一种或多种方式来实施上述策略： · 优化内容重新设计动态内容，以减轻站点体系结构负担。可以编写更智能（smarter）的ASP或更改站点，以降低普通用户调用重Cheavy ASP的次数。 · 提高服务器性能（升级）添加速度更快的&’( 和内存；升级到速度更快的软件，如从windows NT 升级到Windows 2000；并通过优化配置来调节服务器。 · 添加服务器（扩展）向@6: 群集添加更多的服务器。采取这些措施之前以及之后通过分析站点来测量改变之后的效果，然后比较结果。这也有助于预测未来可能发生的变化。 4、规划网络容量原则 在规划@6A 站点的容量需求时，需要遵循下列原则： （1）通过开展市场分析（如果站点还没有发布）或分析WEB服务器的日志（如果站点已经在运行）确定同时用户数量。 （2）使用高峰通信量来确定最大同时用户数量。 （3）根据高峰同时用户数量来计算硬件和网络带宽。处理器功率和RAM必须充足，以避免高峰使用时间性能降低。存储应当非常充足，能保证@6: 站点所需的性能和可用性。 （4）站点拓朴结构必须考虑到服务器操作，如备份和复制、预期使用尖峰时段期间的性能、可用性需求，以及预期的未来增长。 （5）实施站点之前对其进行测试。 （6）将站点升级或扩展。扩展通常会大大提高性能，而且可提供更高的操作灵活性。 适应不断的需求变更。 下面，本文以一个简单的小例子来说明如何在软件开发中应用敏捷建模。 投资方在他需要的财务管理系统中，对商品采购入库的核算有如下要求：根据进项税发票调用业务系统数据，由系统自动制作会计凭证。于是，开发人员就可以用非常简洁的模型来表达这个需求然后，开发设计人员根据该图完成该需求的开发工作。很显然，这个功能很容易就被实现了。这就是第一次迭代过程。然后当演示给投资方时，他们的反馈如下： 由于公司的发展壮大，业务量增加很快，而且进口商品的采购也已经成为经常性业务，因此有如下要求： 1.在财务中，商品采购分为国内商品采购和进口商品采购分别核算； 2.在进口采购中，记帐的依据是进口发票和税单，而且记帐科目是物资采购； 3.国内采购中，记帐科目是库存商品。 根据这些反馈，设计人员对上述功能进行了调整，首先，必须将原商品采购模块一分为二———进口采购和国内采购，原模块可以扩充为国内采购模块，进口采购模块则需要重新开发。于是，很快就完成设计 应该说，到目前为止，变化的需求已大部分被修改并实施到软件中了。此时已经经历了两次迭代。然后又可以把开发完成的软件拿到客户那里去演示了，也许客户又有了新的要求，比如说，为避免业务上的数据有问题，应该允许财务人员手工录入核算信息，于是开始了第三次迭代过程。依次类推，也就实践了敏捷建模的迭代思想。 当然，本人并不认为要完全遵照敏捷建模的方法去完成需求管理，我们必须结合软件工程中需求管理的方法和流程，将敏捷建模的思想融入在需求管理过程之中。 虽然，需求管理到目前为止尚无定法，但是只要我们在实践中不断探索，不断总结，就一定能不断的完善需求管理。