第二部分——MSIB 2.0 站点的性能和可扩展性
这一部分简单介绍了 MSIB 项目组在实现站点代码和实际 MSIB 2.0 部署所需的吞吐量和可扩展性需求时所采用的步骤。 这一部分并不介绍 ASP.NET 编码做法、Microsoft Internet Information Services (IIS) 5.0 调节参数或 SQL 服务器的调节参数。
为了优化 MSIB 2.0 站点的性能，MSIB 开发组对以下内容做了调查：
| • |
分析 SQL 服务器 |
| • |
使用高速缓存方案 |
| • |
调节硬件 |
| • |
调节 IIS |
| • |
横向扩展 Web 群 |
分析 SQL 服务器
优化站点软件性能和可扩展性的第一步就是分析后端 SQL 服务器的使用情况。 MSIB 项目组为站点内的每个页面进行了一次 SQL Query Analyzer 追踪。 以下是免费文本搜索页面的输出结果：
EventClass TextData CPU Reads Writes Duration SPID StartTime
SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05
11:07:16.513
SQL:BatchCompleted select * from CatalogGlobal where [CatalogName] =
N'ANVIL0' 0 2 0 0 52 2000-12-05 11:07:16.513
SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05
11:07:16.513
SQL:BatchCompleted SELECT A.* FROM CatalogAttributes A, syscolumns S
WHERE S.id = OBJECT_ID('ANVIL0_CatalogProducts') AND A.propertyname =
S.name ORDER BY A.PropertyName 15 55 0 16 52 2000-12-05 11:07:16.513
SQL:BatchCompleted EXEC sp_GetResults_for_AllColumns N'ANVIL0', N'*',
N'FREETEXT (*, N''testasdf'' )', '', 1,11,1,39 32 1147 0 76 52 2000-12-
05 11:07:16.530
SQL:BatchCompleted EXEC sp_CheckCatalog '*', 'ANVIL0', 'FREETEXT (*,
N''testasdf'' )' 0 29 0 0 52 2000-12-05 11:07:16.607
MSIB 项目组的第一项查询优化措施就是在追踪分析过程中发现的。 MSIB 项目组在页面上查找重复的查询并减少冗余的 Select 语句。 MSIB 项目组很好地跟踪了目标的信息并对代码重新排序，使得查询操作只能进行由条件调用，从而完成了这一步骤。
接下来， MSIB 项目组从磁盘读取的角度确定了最为昂贵的查询。 为了简化这些操作，MSIB 项目组尝试着降低查询操作的 I/O 复杂性。 例如，改变 Select * 语句，使其归入隔离更好的返回子集中。
最后，MSIB 项目组通过 SQL 服务器调节向导重放了记录下的跟踪结果。 该向导建议对表格索引进行一些变更。 所有这些页面级变更的组合降低了后端 SQL 服务器的负荷并因此改善了 MSIB 2.0 Web 站点的可扩展性。
在 SQL Server 服务器上，MSIB 项目组保留了与性能有关的所有默认配置。
使用高速缓存方案
提高吞吐量的下一步就是利用应用服务器中的高速缓存。 MSIB 项目组利用了以下的高速缓存方案以优化 MSIB 2.0 站点的性能。
页面输出高速缓存
Microsoft .NET Framework 系统内内置了页面输出高速缓存。 关于 MSIB 项目组如何使用这种功能的详细情况在 MSIB Developers Guide 中有所介绍，该资料随 MSIB 2.0 提供。 这种高速缓存方案对于未经个性化的页面是有效的，例如那些未用个性化内容对象（PCO）显示 Microsoft Content Management Server （MCMS）的页面。
MCMS 服务器的性能
Microsoft Content Management Server (MCMS) 2002 可以在纵横两个方向上进行扩展。 目前正在编写一份关于 MCMS 部署的文件，其中讨论了各种可用于 MCMS 的高速缓存方法。 在编写完成之后，可以从以下地址得到该文件 http://go.microsoft.com/fwlink/?LinkId=15170。如需了解关于 MCMS 2002 高速缓存的更多信息，参见 MCMS 2002 Help 中的“Optimizing MCMS Site Performance”。 如需了解关于利用 MCMS 2002 SCA 设置高速缓存属性的更多信息，参见 MCMS 2002 Help 中的“Specifying cache properties”部分。 如需了解 MCMS 性能的更多信息，参见 MCMS 主页，地址在 http://go.microsoft.com/fwlink/?LinkId=8426.
调节硬件
在进行性能分析的过程中，为 Web 服务器和 SQL 服务器选择正确的硬件发挥着非常重要的作用。 此外知道如何为这些服务器选择正确的硬件还能够让您为其他用户提供相关硬件的建议。 这一部分介绍了 MSIB 项目组是如何为本文所述的测试选择 SQL 服务器的。
Web 服务器
在为 Web 服务器选择硬件的时候， MSIB 项目组考虑了以下几个方面：
| • |
内存 |
| • |
磁盘子系统 |
| • |
网络系统 |
| • |
CPU |
内存
MSIB 项目组为 Web 服务器配置了较大的随机存取存储器（RAM），所配容量超出了服务器运行任务所需的量。 为了确定服务器可以减少多少物理 RAM 内存，之后项目组计算了在工作负载下服务器的最大工作集。 一个典型部署所需的 RAM 数量取决于您为该部署对高速缓存和内存的需求。 不过，在大多数情况下，1GB 的物理 RAM 已经是足够的了。
磁盘子系统
MSIB 站点前端 Web 服务器的磁盘子系统作为一个只读设备，是用来存储自举分区和站点内容的。 这一子系统必需要有读/写设备才能进行文件分页操作，不过如果有足够的物理存储器支持系统的话，这些操作都是最低限度的要求了。 Web 服务器确实是利用磁盘子系统写事件日志和 Web 日志的。 这种操作已经由 Windows 2000 操作系统进行了很好的调节，很少需要超过一个内存芯片才能达到所需性能的。
网络系统
Web 服务器上的网络系统至少应当包括一块 100BaseT 的网卡。 要实现更高的安全性、可管理性和可用性，服务器应该配备两块甚至三块网卡。 在 MSIB 项目组的测试中，web 服务器的网路吞吐量并不足以用完一块 100 兆位的网卡能力。
CPU
最后，应当为服务器选用当前最好的 CPU 和处理子系统。 在可以预见到的将来，这个特别的硬件子系统仍将是该服务器的瓶颈。 这是因为动态 Web 页动态和过程全面的性质造成的。
确定适当的 CPU 数量是 Microsoft Server 每处理器许可计划的一项要求。 要确定这一需求，需要对您的 MSIB 2.0 站点进行一次 TCA 分析，在本文前面的“使用 TCA 方法进行容量规划”一部分对此做了介绍。
SQL 服务器
MSIB 项目组利用本部分介绍的指南建立起了 SQL 服务器，使之并未成为 MSIB 2.0 部署中的瓶颈。
在为 SQL 服务器选择硬件的时候， MSIB 项目组考虑了以下几个方面：
| • |
内存 |
| • |
磁盘子系统 |
| • |
数据库 |
内存
大量的随机存取存储器（RAM）对于 SQL 服务器是有好处的，因此您应当依照数据库的工作集权衡 RAM 的数量。 在运行的时候测试网络的输入/输出 （I/O）。 SQL 服务器的处理负荷将是访问 SQL 服务器数据库的前端服务器数量以及负荷配置文件的正函数。
磁盘子系统
一般情况下， SQL 服务器最重要的调节选项就是安装物理磁盘子系统。 为了获得最佳性能，数据库应当与它们在不同物理驱动器上的业务处理记录分离开来。 您应当建立起所有的数据库、业务处理记录和 TempDB ，这样才不致让单个的磁盘子系统成为瓶颈。 在 MSIB 项目组的测试方案中，磁盘子系统并未成为一个问题。 不过，对于正在运行中的站点来说，您应当认真地将磁盘成本和交易联系起来考虑，以便为增加的磁盘需求做好规划。
数据库
MSIB 2.0 的设计使其可以进行横向扩展并为后端数据库系统分区。 用于营销、用户配置文件管理、目录、数据仓库、交易、内容和管理的数据库可以分离开来，放到物理 SQL 服务器数据库中。 这样一来您就能够轻松地按照数据库将部署系统分配到独立的服务器或群集上去。 关于如何做到这一点的详细介绍在随 MSIB 2.0 附带的 MSIB 2.0 部署指南中可以找到。
调节 IIS
为了进行本分析，MSIB 项目组对前端 web 服务器进行了最小限度的调节。 在默认 Web 站点的 Properties 页面的 Performance 选项卡上，性能调节块被改变为每天超过 100000 次命中的数值。 所有其他的设置都保持原状。 如果您必需要在测试站点或实际站点中改变任何参数的话，那么请每次只改变一个，然后将新的结果与旧结果加以比较。
重要事项： 对这些参数中的任何一个进行不适当的改变可能会给站点管理带来麻烦。
Web 群：MSIB 2.0 站点的扩展
如果所需的 CPU P4EM 比单台服务器所能提供的能力大，那么 Web 群将需要用到多台 Web 服务器。 出于可用性和可靠性的考虑，MSIB 项目组建议在任何部署中最少都要使用两台 Web 服务器。
第三部分 — MSIB 2.0 站点的可用性
可用性规划和可扩展性规划是非常类似的两项工作。 可用性规划的第一步就是要确定您的业务需求。 作为一项指导，建议您重新审查一下您现有站点的行为，然后将您的站点与竞争对手们的站点加以比较。 如需获得各个竞争对手的可用性和页面等待时间等信息的列表，参见 http://www.keynote.com，地址在 http://go.microsoft.com/fwlink/?LinkId=15046。
有两个站点提供了全面的 Internet 性能和一般性能指导性原则，它们是www.mediametrix.com ，地址在 http://go.microsoft.com/fwlink/?LinkId=15045 和“http://Nielsen-netratings.com”，地址在 http://go.microsoft.com/fwlink/?LinkId=15043。
您可以按照不同级别的可用性部署 MSIB 2.0 解决方案。 应当在规划阶段中确定您的 MSIB 2.0 站点的可用性目标。
这一部分介绍了可用性，概述了可能会造成您的 MSIB 2.0 站点不可用的事件，提供了高可用性技术和建议，介绍了如何避免单点故障，并讨论了 MSIB 2.0 企业部署的恢复模型。
本部分包括：
什么是可用性？
使站点不可用的三类事件
高可用性技术和建议
避免单点故障
MSIB 2.0 企业部署的恢复模型
确定预期的可用性
文章来源于领测软件测试网 https://www.ltesting.net/