概述
本文评价了 Microsoft® Solution for Internet Business（MSIB）2.0 版的性能和容量、可扩展性和可用性等特征，并为检验和测量这些特征提供了一个流程。 您可以利用这一流程判断用户负载如何影响硬件资源以及资源如何变成性能的瓶颈。 您可以将这些信息用于：
| • | 评估增添资源的性能。 |
| • | 确定哪些资源可以满足更大的容量需求。 |
| • | 计算某一特定硬件配置的最大能力。 |
本文中用于计算 MSIB 2.0 站点容量的方法被称为交易成本分析（TCA）。 如需了解对 TCA 过程更为深入的讨论，可以参见以下网址上的 Capacity Planning Using Transaction Cost Analysis Methodology ：http://go.microsoft.com/fwlink/?LinkId=9498。
本文假设：
| • | 您是一位 IT 人士，对 MSIB 2.0所用的所有软件和硬件技术都有实际工作经验。 本文特别着重介绍了 Microsoft Internet Security and Acceleration ( ISA ) Server、SQL Server ? 2000、SharePoint? Portal Server 和带 MSIB 2.0 的 IIS 5.0 组件的 Windows® 2000 Advanced Server。 |
| • | 您对 MSIB 2.0 的基础和企业部署都比较熟悉。 |
如需了解关于 MSIB 2.0 及其相关组件以及其基准和企业部署方面的更多信息，可参见下面地址处的 MSIB Overviewhttp://www.microsoft.com/china/technet/itsolutions/techguide/mso/msib/default.mspx.
本文分成三个部分论述。 下表介绍了这三个部分。
第一部分 — 性能和容量规划 | 提供了监控 MSIB 2.0 站点性能的信息，以及将这些性能数据用于容量规划特别是如何利用 TCA 方法在您的 MSIB 2.0 站点上进行容量规划等信息。 本部分还介绍了 MSIB 项目组如何利用这种方法改善了 MSIB 2.0 站点的代码以及软硬件配置的。 |
第二部分 — MSIB 2.0 站点的性能和可扩展性 | 由于 MSIB 2.0 站点的可扩展性与其性能和可用性是紧密相关的，因此在整个文章中都为您提供了如何缩放您的 MSIB 2.0 站点的信息。 不过，在“ MSIB 2.0 的性能和可扩展性”这一部分中对 MSIB 项目组实现站点代码和实际 MSIB 2.0 部署所需的吞吐量和可扩展性需求所采用的步骤给出了介绍。 |
第三部分 — MSIB 2.0 站点的可用性 | 介绍了软硬件可用性方法是如何在该解决方案中工作的，讨论了用于测试和分析一次部署的可用性的方法，并为更加精确地计算可用性提供了一个数学分析。 |
执行摘要
根据本文所搜集的数据，对运行企业和基本部署的 MSIB 2.0 解决方案的性能和容量、可扩展性和可用性等方面可以得出以下几个结论：
性能和容量
| • | 在企业部署中的 Web 服务器为两处理器 1.4 千兆赫兹 （GHz）的，在六天零 19 个小时的期间内，每台服务器的处理能力都维持在每秒 82.88 次请求的级别上， CPU 的利用率约为百分之75左右。 这相当于预定使用方案中所定的 3027 名并发模拟用户的情况。 |
| • | 在基准部署中的 Web 服务器为两处理器 1.4 千兆赫兹 （GHz）的，在六天零 20 个小时的期间内，每台服务器的处理能力都维持在每秒 92.43 次请求的级别上， CPU 的利用率约为百分之75左右。 这相当于预定使用方案中所定的 3376 名并发模拟用户的情况。 |
| • | 一台四处理器的带足够的驱动器容量的 1.4 GHz SQL 服务器在用于数据库存储的时候可以支持大约七台 Web 服务器的网上需求。 在本文所述的测试中，Microsoft® SQL Server 2000 Enterprise Edition Server 内包括了所有的 MSIB 数据库。 在本文所述的使用概况和站点概况下， MSIB 项目组进行了测试，结果表明 SQL 服务器上的 磁盘吞吐量需求并未在性能上产生瓶颈。 这是因为 Web 服务器上的请求都是高度缓存的。 要决定一个实际站点需要的确切配置和 SQL 服务器数量，必需要利用准确的客户数据进行更为详细的交易成本分析 （TCA）。如需了解关于进行详细 TCA 的信息，参见“Capacity Model for Internet Transactions and Using Transaction”用于站点容量规划的成本分析，地址在http://go.microsoft.com/fwlink/?LinkId=9498。 |
可扩展性
| • | 在 SQL 服务器等支持数据层服务器适当增加不致造成瓶颈的时候，可以使用网络负载均衡(NLB) 服务对多台 Web 服务器进行线性升级。 |
可用性
| • | MSIB 2.0 的企业部署计算得到的系统可用性为 99.616%，这一结果是通过测量群集要素的故障切换和恢复时间得出的。 这一可用性计算结果意味着每个服务器群集的平均无故障时间为一星期。 如果目标平均无故障时间 ( MTTF) 增加到一个月，那么系统计算得到的可用性为 99.910%。 |
第一部分——性能和容量规划
这一部分提供了关于监控 MSIB 2.0 站点的信息以及根据这些性能数据利用交易成本分析(TCA)方法进行容量规划的信息。 对 MSIB 2.0 进行容量规划的目的是利用可接受的响应时间支持交易吞吐量，而同时将主机平台的总拥有成本降到最小。 传统的解决方案常常试图从一般基准测试的测量结果进行推论得到使用成本。 然而，更为有效的方法是基于交易成本分析（TCA）的。 本部分还介绍了 MSIB 2.0 项目组如何利用 TCA 方法改善了 MSIB 2.0 站点的代码以及软硬件配置的。
本部分包括：
性能监控
交易成本分析
性能监控
MSIB 2.0 Web 站点是围绕着企业级内容易管理 Web 站点的概念设计的。 本站点是为那些希望利用类似功能创建站点的企业设计的快速上市的平台。 与大多数软件情况类似，该站点尚未得到完全优化，总有改进的余地。 您应当利用以下的性能计数器监控您的 MSIB 2.0 站点的性能。
关键性能的计数器
很多性能目标都是内置于 Microsoft Windows® 2000 操作系统及其他 Microsoft 应用程序和服务中的。 您利用性能计数器可以跟踪这些目标的性能。
MSIB 项目组利用以下的性能计数器分析 MSIB 2.0 站点的性能。 下面给出的性能计数器是以如下格式编写的：性能目标\性能计数器.
ASP.Net\请求的执行时间 | 测量处理一个 ASP.NET 脚本所花的时间。 如果计数器的数值显著增大或者请求的执行时间超过了一秒钟，那么该系统就是在超过其最优能力工作。 为 MSIB 站点设计的页面在一秒之内可以很好地工作。 |
ASP.Net \请求/秒 | 每秒钟请求一个 ASP.NET 脚本的次数。 |
ASP.Net \请求的等待时间 | 测量一个对 ASP.NET 页面的新请求在开始被处理之前等待的时间。 |
内存\可用兆字节数 | 以兆字节(MB)测量服务器上可以用于运行过程的内存大小。 如果可用内存过低，服务器将开始把内存分页到磁盘。 计数器的绝对最小编号为四，不过还是建议维持服务器内存的空间以获得最佳性能。 |
内存\页面/秒 | 测量正在对硬盘进行的实际内存请求。 计数器的大编号是一种关键指标，表明您的系统缺乏内存资源或者是一个实施不良的解决方案。 |
网络接口\字节总数 | 代表某一网络适配器网路吞吐量的总数。 如果您的服务器中包含了多个您想监控的网络适配器，那么您必需要为每个网络适配器单独配置一个计数器实例。 这是用于跟踪网路吞吐量的关键计数器。 |
NTDS\NTLM 身份验证/秒 | 每秒钟进行的 NT LAN Manager (NTLM)身份验证次数。 |
物理磁盘\
%磁盘时间， 物理磁盘\
磁盘读取/秒， 以及
物理磁盘\
磁盘写/秒 | 这三个计算器是用来跟踪磁盘子系统中的活动的。 磁盘子系统很容易成为任何系统中的瓶颈。 在前端 Web 服务器上，磁盘利用率应当是非常低的，这是因为一个页面所用的内容和图像应当能够在文件系统的高速缓存中很好地匹配。 基本的磁盘活动是日志文件，在 Windows 2000 中对日志文件进行了很好地调整以便获得高性能。 相反，SQL 服务器则广泛采用了物理磁盘子系统。 对于快速的 Microsoft SQL Server 2000 计算机来说为 SQL 服务器规划和校准这一子系统尤其关键。 |
处理器\%处理器时间 | 处理器执行一个非空闲线程的时间百分比。 在容量性能测试中，处理器应当保持在一个特定限额之下。 这一限额可以是监控工具的目标，也可以是已经由数据中心人员设定的限额。 为了进行我们的测试，该限额被设为百分之 85 。 |
SQL 服务器：数据库\交易/秒 | 表示每秒钟为数据库发起的交易数量。 这一计数器是后端 SQL 服务器活动的关键指标。 |
系统\上下文转换/秒 | 表示系统从一个线程切换到另一个线程的次数。 如果该计数器增加到每处理器 5000 以上，这表示服务器和/或应用程序的对称多重处理(SMP)的可扩展性较差。 Windows 2000 和 Microsoft Commerce Server 2002 的组件都可以很好地缩放。 |
Web 服务\Get 请求/秒 | 表示每秒钟使用 Web 服务试图发起的 HTTP GET 请求速度。 这是用于判断吞吐量的关键计数器。 |
如需了解关于性能计算器的更多信息，参见 Windows 2000 Server 帮助中的“性能目标和计数器”部分。
如需了解建议用于监控您的 ISA 服务器性能的性能计数器的信息，参见http://go.microsoft.com/fwlink/?LinkId=14746。
交易成本分析
这一部分介绍了 MSIB 项目组用以为 MSIB 2.0 站点计算交易成本分析(TCA)的使用概况和站点概况，并总结了 MSIB 项目组在典型的企业和基准 MSIB 2.0 部署中进行的交易成本分析(TCA)得到的操作成本。 此外，该部分还介绍了如何使用 TCA 方法在 MSIB 2.0 站点上进行容量规划。 从最开始的意义上说，利用该分析方法的最符合逻辑的地方是在销售阶段中决定许可证数量的时候。
部分包括：
使用和站点概况
操作成本摘要
使用 TCA 方法进行容量规划
使用和站点概况
本部分介绍了 MSIB 项目组用以为 MSIB 2.0 站点计算交易成本分析 (TCA) 的在线使用概况、 MSIB 使用概况和站点概况。 要执行一个 MSIB 2.0 站点的 TCA ，您必须首先创建一个使用概况和站点概况。 然后您才能够利用 TCA 方法计算您的站点容量，这种方法将在本文后面的部分加以介绍。 编制使用概况的过程在“Commerce Server 2002 Creating a Usage Profile for Site Capacity Planning”中有详细介绍，地址在http://go.microsoft.com/fwlink/?LinkId=9498。
在线使用概况
在线概括描述了在线时 MSIB 2.0 站点的使用情况。 这一概括不包括 MSIB 2.0 站点离线时可能发生的任何操作。 下表列出了本文中 MSIB 项目组所用的在线使用概括。 峰值乘数用于计算与平均负载有关的系统的最大容量。 如果每秒钟的平均请求数量是 50 ，如果您的峰值乘数是 3 的话那么预期峰值将会是每秒钟 150 次请求。 为了对实施 MSIB 2.0 进行容量规划，您应当为系统的峰值容量做规划。
会话的平均时间 | 6 分钟(360 秒) |
峰值乘数 | 3x 平均值 |
每个用户每次访问的请求数 | 6 |
MSIB 使用概况
下表列出了本文中 MSIB 项目组测试的 MSIB 2.0 操作使用概况。 这些测试值是通过分析 Web 站点信息流量得到的。 注意以下方面：
其中分布权重一栏给出拉某类操作占总请求数的百分比。
其中标准化一栏表示分布百分比乘以前表给出的每用户每次访问请求数得到的结果。 注意这一栏合计达6。
其中每个操作的请求数一栏给出了执行某一操作所用的用户请求数量。 由于回帖或服务器重定向等原因，有些操作会产生多个 ASP.NET 请求。
其中每个会话的请求数一栏给出了用户在每次会话中发起的对某一操作的请求数量。
匿名浏览 | 27.33% | 2.00 | 2 | 3.28 |
匿名目录搜索 | 7.65% | 0.56 | 2 | 0.92 |
匿名内容搜索 | 7.65% | 0.56 | 2 | 0.92 |
匿名企业页面 | 10.93% | 0.80 | 2 | 1.31 |
匿名主页 | 27.33% | 1.00 | 1 | 1.64 |
浏览 | 6.00% | 0.44 | 2 | 0.72 |
目录搜索 | 1.68% | 0.12 | 2 | 0.20 |
内容搜索 | 1.68% | 0.12 | 2 | 0.20 |
企业页面 | 2.40% | 0.09 | 1 | 0.14 |
主页 | 6.00% | 0.22 | 1 | 0.36 |
注册新用户 | 1.33% | 0.10 | 2 | 0.16 |
总计 | | 6 | | 9.86 |
站点概况
MSIB 项目组为本文进行的测试中所用的目录数据库包含了四种语言编写的一百万条项目。 搜索页组是利用均匀分布方式在一万个项目的子集中挑选的。 UPM 数据库中包含了一百万个用户。 MSIB 项目组测试了一个有 100 条信道，每条信道 100 条记录的 MSIB 2.0 站点。
操作成本摘要
本部分列出了用户访问 MSIB 2.0 站点时可以执行的每种操作的典型核心成本。 这些成本是根据 MSIB 企业部署和基准部署计算的，这些部署中使用的软硬件配置如“附件 A -hardware and Network Topology Details”所述。 成本以 P4EM 描述，如本文前面部分“术语定义”所述。 注意，两种部署下的 SQL P4MC 是一样的。
下表给出的一些操作涉及到多个 ASP.NET 页面或 HTML 请求和发布。 每一种成本都表示系统运行在最佳吞吐量下，在这些测试中前端 Web 服务器的 CPU 利用率采用百分之 85，计算得到了这些成本。
为了进行数学分析，在后面的方程中将会把该表看成一个矩阵。
匿名浏览 | 11.56 | 11.08 | 1.950 | 这一组操作是由一位未登录到 MSIB 站点的用户进行的。 匿名用户是通过产品目录页面进行浏览的。 |
匿名目录搜索 | 28.65 | 28.65 | 28.00 | 这一组操作是由一位未登录到 MSIB 2.0 站点的用户进行的。 该匿名用户发起一个请求并收到一个搜索响应。 |
匿名内容搜索 | 57.38 | 40.63 | 6.790 | 这一组操作是由一位未登录到 MSIB 站点的用户进行的。 该匿名用户正在执行内容搜索功能。 |
匿名企业页面 | 12.70 | 12.57 | 1.680 | 这一组操作是由一位未登录到 MSIB 站点的用户进行的。 该匿名用户正在浏览内容管理服务器提供的模板和内容。 这一页组包括丰富的产品记录。 |
匿名主页 | 11.54 | 10.52 | 3.080 | 这一操作是由一位未登录到 MSIB 站点的用户进行的。 这一操作由一位匿名用户发起，该用户请求进入 MSIB 2.0 站点的主页。 |
浏览 | 19.69 | 24.38 | 2.800 | 这一组操作是由一位已登录到 MSIB 站点的用户进行的，该用户正在浏览各种类页面。 |
目录搜索 | 31.99 | 31.99 | 106.21 | 这一组操作是由一位已经登录到 MSIB 2.0 站点的用户进行的，登录之后该用户搜索了一个目录。 |
内容搜索 | 33.98 | 32.44 | 6.790 | 这一组操作是由一位已经登录到 MSIB 2.0 站点的用户进行的，登录之后该用户使用了 Microsoft 内容管理服务器(MCMS)的内容搜索功能。 |
企业页面 | 18.52 | 21.57 | 104.77 | 这一操作是由一位已经登录到 MSIB 站点的用户进行的，登录之后该用户请求进入该 MSIB 2.0 站点的一个企业页面。 |
主页 | 20.64 | 24.34 | 2.800 | 这一操作是由一位已登录到 MSIB 站点的用户进行的，登录之后该用户请求进入 MSIB 站点的主页。 |
注册新用户 | 53.07 | 60.11 | 31.800 | 这一组操作是由一位在该站点新注册的用户执行的。 |
使用 TCA 方法进行容量规划
本节提供了为 MSIB 2.0 站点进行容量规划所用的数学计算方法。 您可以利用交易成本分析 (TCA) 方法将站点中的每项操作隔离开来，以便进行性能调节。 利用 TCA 方法您还可以利用不同的使用配置文件和类似的页面组计算 Web 站点的容量。 类似地，当您要改变 Web 站点的单个页面组的时候，您可以简单计量一下与单个页面组相关的新成本从而规划其容量。
每用户频率的操作
The每用户频率的操作如下表所示。 这个频率是根据定义的使用配置文件获得的统计结果。每秒钟每位用户的操作次数一栏给出了每位并发用户的操作频率、或请求比率。
每秒钟的请求频率=每个会话的请求数/会话的平均时间
其中每个会话的请求数来自于每个会话的请求数一栏，位于MSIB 使用配置文件表中，而会话的平均时间来自于联机使用概况.
这样一来，对于匿名主页操作来说；
1.64每个会话的请求数/ (6分钟*60秒) =0.004556每个用户每秒钟的请求数。.
匿名浏览 | 0.009111 |
匿名目录搜索 | 0.002551 |
匿名内容搜索 | 0.002551 |
匿名企业页面 | 0.003644 |
匿名主页 | 0.004556 |
浏览 | 0.002000 |
目录搜索 | 0.000560 |
内容搜索 | 0.000560 |
企业页面 | 0.000400 |
主页 | 0.001000 |
注册新用户 | 0.000444 |
总计 | 0.027378 |
频率乘以成本
下一步是要将频率乘以 Web CPU 和SQL CPU 等硬件资源的成本。 例如，一项操作的 CPU 成本是：
每个用户每秒钟的操作成本( 单位：P4EM ) =频率*P4MC 成本
其中频率来自于上表的每秒钟每位用户的操作次数一栏，而P4MC 成本来自于本文操作成本摘要部分中表格的 Web P4MC 栏。columns of the table in theOperation Costs Summarysection of this document.
这样一来，对于匿名主页操作来说；
0.004556每秒钟每位用户的操作次数* 11.54 P4MC = 0.05258 P4EM
这样就得到了每位并发用户如下的成本矩阵：
匿名浏览 | 0.10528 | 0.10095 | 0.0178 |
匿名目录搜索 | 0.07309 | 0.07309 | 0.0714 |
匿名内容搜索 | 0.14638 | 0.10365 | 0.0173 |
匿名企业页面 | 0.04628 | 0.04581 | 0.0061 |
匿名主页 | 0.05257 | 0.04792 | 0.0140 |
浏览 | 0.03937 | 0.04876 | 0.0056 |
目录搜索 | 0.01791 | 0.01791 | 0.0595 |
内容搜索 | 0.01903 | 0.01817 | 0.0038 |
企业页面 | 0.00741 | 0.00863 | 0.0419 |
主页 | 0.02064 | 0.02434 | 0.0028 |
注册新用户 | 0.02359 | 0.02672 | 0.0141 |
总计 | 0.55000 | 0.51595 | 0.2544 |
根据 CPU 容量计算最大并发用户数
下一步是要根据 CPU 容量按照如下方式计算最大并发用户数：
一个系统的 CPU 容量是用处理器数量乘以 CPU 的 MHz 定额得到的。 因此，对一台安装了两个 2 GHz 处理器的计算机来说；
CPU 容量= 2 x 2000 MHz = 4000 P4EM
The工作载荷下的系统目标 CPU 容量通常由 IT 部门决定。如果没有这方面的标准可循，那么您应比照着平均的长期载荷对峰值载荷进行分析，据此决定这一目标值，确保 CPU 在100％容量以下运行。 假设一台计算机在 85％ 的容量下运行，那么应该按照如下方式计算其目标 CPU 容量：
目标 CPU 容量= 4000 P4EM 的 CPU 容量x0.85=3400 P4EM
为了根据目标 CPU 容量和总用户成本计算 Web 服务器的目标用户容量，在前表中找到每位并发用户 Web CPU 的总成本（0.55000）。 然后将这一成本分成目标 CPU 容量。
目标用户容量=目标 CPU 容量每个用户 Web CPU 总成本Web CPU cost per user(基础 Web P4EM)
= 3400/ 0.5500 = 6182 并发用户
服务机会
您应当把交易成本分析（TCA）和可用性规划看作是一种服务机会。 应当将本文祥述的步骤看作是用于管理 MSIB 2.0 站点可用性的最佳做法。
