中文对白：

大家好，我叫Brad Waters，是Windows性能小组的成员。今天，我要向你们介绍Windows .NET Server 2003在性能和可伸缩性方面的重大改进。

我的讲话将涉及诸多不同的领域，而这实际上不仅仅是性能小组，也是Windows核心开发小组以及其它一些与我们协作的小组共同努力的结晶。我们将首先从数据库服务器（Database Server）开始。

数据库服务器在性能上已经显露出重大的改进，比如配备32颗处理器系统的吞吐量增加了2到3倍。这就使得Windows可以很好地进行伸缩并工作于大型企业系统上。

数据库服务器的改进对于系统上其它所有服务器也很重要，因此我们将先谈谈这方面的内容。下面，我将说一说Web服务器（Web Server）。Web服务器已经被彻底重新设计了。与Windows 2000中的IIS 5.0相比，IIS 6.0的结构已经有了巨大的改变。

下面，文件服务器（File Server）在客户机和服务器的缓存方面有所改进。可伸缩性有了很多改进，而8处理器的性能提高了2倍。虽然你们硬件的使用时间各异，但是一些改进或多或少会有所体现。

如今，你们当中有许多人告诉过我们，他们要我们同关注其它领域一样关注Active Directory（Active Directory）。我们在Active Directory上花了很多时间，以提高性能并使其更易使用。此外，8处理器系统的性能和可伸缩性均得到了2到3倍的提高。

下面，与Windows 2000相比，终端服务器（Terminal Server）在Windows .NET Server 2003上的将具有更大的容量。这些改进首先体现在内存管理上。我们在内核中使用了虚拟地址空间，其效率要比Windows 2000高得多。

最后，网络连接是整个系统中另一个得到重大改进的领域，对每个应用程序均有帮助。我们已经看到，实际的网络性能提高了20%到25%，始终紧追网络应用程序。而网络应用程序的吞吐量则增加了5倍。

现在，让我们来看一看数据库服务器。

在数据库服务器中，使用最多的内核是程序调度、内存管理和磁盘输入/输出（I/O）部分。数据库服务器中更令人兴奋的方面是对于64位硬件，比如Itanium 2的支持。

目前，我们可以在配备512GB内存的Itanium 2上最多支持64个处理器。对于目前的情况来说，512GB的内存真的是非常庞大。许多数据库都将采用这一规格的内存。在x86上，我们现在也可以支持64GB的内存，而在Windows 2000中所能支持的最大内存为32GB。

我们是通过考察主要的系统锁来实现这些改进的。我们有一些很复杂的工具，如总线分析器和软件工具，使我们可以真正地了解系统总线的使用情况。

通过使用这些工具，我们可以知道哪些系统锁被最多地争用，从而予以集中消减。我们还可以对实际的内核数据结构进行优化，以让你们获得更好的性能和可伸缩性。

除了对Itanium 2等Windows硬件支持外，还包括对超线程技术的全新支持。超线程技术是由最新的Intel Pentium 4芯片引入的一种允许多个逻辑处理器共存于一个单一处理器上的能力。

其真正目的是为了叠加多个线程，让它们可以更有效率地使用处理器，避免处理器停止运转。这样，即便你只有一颗物理处理器，单处理器系统也会表现得犹如双处理器系统。

虽然Windows 2000支持超线程技术，但是在我们真正拥有超线程硬件前，Windows 2000就已经发行。因此，我们就有了机会对整个系统进行很多、很多的改进，从而比以前更有效率地使用超线程技术。

下面，我将根据后边的幻灯片稍微再谈一下非均一内存访问（Non-Uniform Memory Aclearcase/" target="_blank" >ccess，NUMA）。NUMA是一种用于设计超大型系统的技术，它使用一种构件块技术支持超大型系统。系统中，处理器被分成约4个为一组，在画面上以横线相连。

最后，输入/输出通道在伸缩性和性能上均有所改进。许多改进要归功于调度程序和内存管理的改变，其它改进则是由于我们在很大程度上改进了Windows .NET Server 2003中的输入/输出代码路径。

在这里，我们可以看到Windows 2000中的一些关键锁。我们有一个调度程序锁，当你拥有8个以上处理器时，该锁会被大量地争用。我们还有一个上下文交换锁、一个页帧锁、系统空间锁和一个内存管理委托锁。这些都是系统上最热门的锁。

如今，通过一些很有趣的技术，我们实际上已经可以除去其中的3个。现在，上下文交换锁、系统空间锁和内存管理委托锁在Windows .NET Server 2003中已经完全不见踪影了。而调度程序锁和页帧锁也已被大大简化了。

我们更少使用到它们了，而在使用时，所用的时间，我们称之为占用时间，也变得更短了。换句话说，它们所保护的数据结构得到了更高层次的优化，用于数据结构的实际指令的使用时间变得更短了。

在这里，可以看到一个典型的NUMA型系统。在这个案例中，我们有4个节点，每个节点有4个处理器。在你们屏幕的左手边，可以看到4个CPU、4个存储芯片（即DIMM）、一个I/O芯片和一条I/O总线。这4个处理器可以一起组成一个典型的商品化系统。

现在，在这张幻灯片上，有一个黄线连接着这些不同的节点。各个节点的运作方式完全一致，但由于每组4个处理器均有本地内存，因而在访问本地内存时，你就获得了更高的性能。所以，许多NUMA特性必然与本地性相关。

对于程序，我们为节点指派了一个程序，然后又设法为该程序分配了内存。而且，我们在同一个节点的程序中对线程进行调度，从而获得最高的性能。 这儿有一个体现我们努力成果的好例子。让我们回想一下我们的伸缩性小组与Microsoft高级管理人员的会面，这次会面的主要目标是要获得一个位列十大TPC-C非群集目录的系统。你们可以访问TPC或事务处理委员会的网站：www.tpc.org。

如果你们要去查看非群集TPC-C的结果，请记住这些结果的有效日期截止到2002年12月14日。我们的目标是获得一个位列该目录的系统，而这一目标已经通过Unisys ES7000于2001年9月实现了。此后，我们又有了很大的进步，目录在整体性能方面有了很大的提高。

与以前相比，我们已经实现了更高的TPC-C吞吐量。现在，TPC-C 的工作负载均属在线事务处理工作负载，包括许多随机的输入/输出和一个工作负载的主要特征，即价格计算，包括磁盘以及对整个系统的维护。

因此，实际的数据库容量，随实际吞吐量扩大后，其成本也随着更高的吞吐量而增加。现在，如果你看一下这个屏幕上的'Total'一栏，你将看到以黄颜色标示的Windows系统在目录的所有系统中，其成本是最低的。

每个事务的实际费用也是相当低的。吞吐量以非常稳定的状态扶摇直上。在2001年，我们首先以146,000个事务处理能力获得了第10的位置，随后我们将这一数字不断地提高。你们将在这个目录上看到两个Unisys ES7000系统。

10号系统，每分钟可处理203,000个事务，拥有Pentium 4芯片。6号系统使用新的Xeon MP芯片，运行频率为2GHz。5号系统非常让人兴奋，因为它是一个运行着32个处理器的64位Itanium 2系统。

如今，与1号系统的128个处理器相比，这已经不值一提了。因此，仅通过32个处理器，我们有望得到更高的名次。

我们继续努力工作以提高名次。对于我们在实验室中进行的测试工作来说，这是一个非常好的工作负载，因为它真实地反映了我们在在线事务处理系统上所付出的努力。 对于下一个工作，我将着眼于TPC-H。TPC-H工作负载同样来自于事务处理委员会，属于策略支持工作负载。这个特殊工作负载的特征是从事大量的数据库扫描。

因此，我们进行了很多输入/输出，趋向于进行连续的输入/输出，因此属于一种连续扫描型的输入/输出，这与我们刚刚谈到的采用少量随机输入/输出的在线事务处理工作负载有着很大的不同。

所以，在这里你们可以看到在100GB的数据库容量上，Windows是仅有的主要系统，占据了前5名的位置。

对于300GB的空间，32位处理器芯片在虚拟地址空间上的限制开始使该工作负载的处理工作变得很困难，因为你没有虚拟地址空间来进行大规模的数据库扫描和联结。

由于这个原因，64位系统，比如这个Unisys ES7000系统，它实际上是一个拥有16个处理器的Itanium 2系统。

这个Unisys系统使我们可以攀升到TPC-H目录上的第三位，因为我们现在已经或多或少拉平了与一些64位Unix系统间的差距，因为我们拥有了可以更好地应付这个特殊的工作负载的地址空间。

现在，这是一张我最喜欢的幻灯片，显示了我们近六年在TPC-C工作负载上所取得的成就。如果你们回顾一下1996年，那年Intel引进了Pentium Pro芯片，正是从那时起，我们开始关注伸缩性，关注大型事务处理系统。

返回来，我们真地对于能够在TPC-C工作负载上每分钟取得7,000个事务感到非常高兴。从那时起，我们将吞吐量提高了44倍，因此我们得到了屏幕右手边，也就是你们的左手边的两个2002年的新系统。这两个系统在最近的几个月得到了多次的升级。

ES7000 32处理器--Xeon MP芯片每分钟运行234,000个事务，而新的NEC系统每分钟运行342,000个事务。另外，你们将在这里看到一条画出的线。这条线实际表示基于工作负载规格的系统上处理一个典型事务所需的成本。

因此，你们可以看到我们不但大幅提高了吞吐量，而且大大降低了总体成本。事实上，如果你登陆TPC网站，查看这些系统的更多详细资料，你就会发现磁盘系统占去了很大一部分成本，而在速度上并没有提高，等同于实际的芯片速度。

这张特殊幻灯片的另一个有趣之处就是，我们从NT 4.0一路升级到Windows .NET Server 2003。我们从SQL Server 6.5升级到了SQL Server 2000新的64位版本，而在硬件方面，我们进行了巨大而极具实质性的改进，从Pentium Pro芯片到Pentium芯片，再到Xeon芯片，再到Pentium 3和Xeon MP，最终到Intel的Itanium 2 64位芯片。

这张幻灯片实际上为你们提供了有关如何使输入/输出子系统在通路长度和伸缩性上的改进在你们的系统中发挥作用的一个很好的办法。这里，我们可以看到在一个基于32位处理器的ES7000系统上，我们可以提高35%的输入/输出吞吐量，减少30%的CPU成本。

现在，我们正在谈论30%和35%的性能改进以及2到3倍，也许更大的吞吐量提升。这些改进实际上表示，同时，也意味着在你的环境中，现在你可以通过所拥有的系统干更多的事情。

换句话说，你可以在已有的系统上获得更大的容量，为你的业务增长提供空间，或者你可以通过合并系统减少系统的数量。不管你怎么想，这些改进将为这些系统带来更低的拥有成本。

下面，我们将谈一谈Web服务器。

如我较早前提到的，Windows .NET Server 2003中的Web服务器已经完全被重新设计了。我们在IIS 6.0中有一个新的程序模型，可以提供更好的性能和可靠性。

另一个你们已经多次向我们询问的特性就是内核模式的侦听程序。这个内核模式的侦听程序以HTTP.sys驱动程序的形式被引入IIS 6.0。

该内核模式的侦听程序的优点在于，频繁使用的网站和网页可以以内核模式进行缓存，然后以极快的速度提交给用户，而不需要进行重新处理。

因此，它可以提供更好的性能，而不需要跨越上下文切换层，不需要从内核模式切换到用户模式。

在路径长度、可伸缩性和整个Web服务器方面，ASP和ASP.NET在脚本上均已经有了很多改进，而且我们将在文件服务器中看到，缓存的能力已经取得了很大的改进。

目前，由于芯片、内存和磁盘间的速度差异，缓存成为操作系统和服务器中的一个非常重要的特性。因此，通过缓存，我们就可以查看频繁请求的内容，并根据它比以前更快地执行操作。

另一个我们的客户多次请求予以改进的领域是网站托管领域。现在，通过IIS 6.0，尤其是内核模式的Web驱动程序和新的程序模型，我们可以提供更好的网站托管服务。我有一张幻灯片，将向你们展示不久前取得的改进成果。 这可以使服务提供商在向你提供网站的同时，提供更经济的环境。在堆栈方面已经取得了很多改进。通过堆栈，你的程序可以动态地分配内存。只要你在C++中执行，如'Malloc'或'New'等命令，你就是在使用堆栈。

在许多服务器应用程序中，堆栈已经成为了一个瓶颈，因此我们投入了许多时间来改进Windows .NET Server 2003中的堆栈。

除了改进已有的堆栈外，我们还引进了一种新的堆栈，称为低碎片堆栈。你可以通过调用一个应用编程接口（API）将其应用于你的应用程序。

顾名思义，低碎片堆栈有助于减少用户状态中的内存碎片，从而为你提供更好的性能，并让你更好地利用数据结构的虚拟和内部存储。

最后，在讲话的最后，我将向你们提供更多有关改进诊断软件的信息。诊断软件始于Windows 2000。事实上，我们已经将其添加到Windows .NET Server 2003中，并进行了改进和扩展。诊断软件构建于Windows中的事件跟踪，我们称之为ETW。

我们已经在整个内核和许多服务器中都设置了规范。如果你是一位应用程序编写者，你就可以将附加的规范随意地在添加到你的应用程序中。

而且，这个规范可以在需要的时候启用，以追踪各种问题和故障，帮助你制定未来的容量规划，并诊断系统的不同特征。

与你以前所见的一些提供了很有用的性能计数器的工具不同，这个工具具有额外的能力，能够为你提供有关响应时间以及每个事务所耗费的资源的数据。

我们正在朝着一个非常振奋人心的方向前进，可以为你提供庞大的信息。

这儿有一张幻灯片，将IIS 5.0与IIS 6.0的运作情况进行了真正的比较。你们可以看到在这张幻灯片上，IIS 6.0有了重大的改进。你在IIS 6这边所看到的HTTP.sys就是我们前面提到的内核模式的侦听程序。

TCP/IP属于网络堆栈。因此，到来的请求都通过TCP/IP和网络堆栈进入Web服务器。在旧的IIS 5.0模型中，这些请求会进入AFD.sys，即我们的WinSock驱动程序，然后再通过WinSock 2.0遍历内核到达用户边界，进入INetInfo程序。

一旦进入INetInfo程序，将对请求进行处理以决定接下来需要采取的步骤。通常，请求都会进入ISAPI程序或其它一些进程，以及ASP进程，以便利用进程外模型对请求真正进行处理。

如果你使用了进程内模型，通常请求会在INetInfo中得到满足。在IIS 6.0中，你可以从网络堆栈中的TCP/IP直接进入HTTP.sys，而不必通过WinSock驱动程序和进入用户模式层。

这就大大简化了路径的长度，从而让你可以更快地处理请求。

如果你需要的话，你就可以这么处理，而且IIS 6.0仍在使用AFD和WinSock模型。但是，这里有许多请求将进入驱动程序，并从缓存得到满足。或者，我们让缓存满足动态请求，我们可以在这将静态请求和动态请求进行一下对比。我们在早期Web服务器中见过静态请求，当时我们采用了可以在计算机的浏览器中拉进拉出的预设置页面。

对于动态请求，我们通常会运行一个脚本。脚本可以由网站管理员或实际访问网站的人进行定义。这里有所不同的是，由于动态请求是动态变化的，所有每次你使用的时候，他们都会发生变化。

然而，动态请求经常会涉及到一些静态内容，因此我们现在可以将其存储在片段缓存中。 所以，在IIS 6.0上，请求将通过TCP/IP进入，经HTTP.sys，然后，如果未被实际的内核模式缓存所满足，将直接进入一个将在IIS 6.0上对其进行处理的进程，从而取消了从INetInfo到ISAPI或ASP等进程的步骤。

由此，你获得了一个更有效率的接口和更高的灵活性。

该进程模型所得到的额外利益始于我们在动态脚本中设置的代码。Microsoft不控制代码的运行，而且代码可能潜在着错误和问题。如果一个实际的脚本存在着一个错误，进程可以根据回收，而不会失去任何一个请求。

因此，除了在性能和可伸缩性方面的改进，还提供了更好的可靠性。

这里对内核模式缓存在HTTP.sys中的运作情况进行了简单的介绍。

请求进入HTTP引擎，来到名字空间映像程序。我们会对其进行检查，以确认是否可以在响应缓存中满足该请求。如果可以，该请求会立即得到满足。如果不行，我们继续从映射程序开始，对请求进行排列以等候一个工作进程。

工作进程将处理结果，然后将其返回到HTTP.sys，最后发送给用户。

现在，我要说几个不同的工作负载。首先从WebBench静态工作负载开始。WebBench是eTesting实验室推出的一个工作负载。eTesting实验室属于Ziff Davis Media Benchmarks。

静态请求是针对网站的传统请求，我们在以前就已经见过了。事实上，它们仅用于提供页面。 现在，你们可以从这张图表上看到，我们不但改善了路径，这在单处理器的情况下显而易见，而且对于4个和8个处理器的情况，可伸缩性真正地实现了提升，并且获得了更好的性能。

现在，这是WebBench，但是请你们看动态内容。在你们屏幕上所显示的是静态和动态请求的混合。这些工作负载使用了ISAPI动态请求，这些请求被我们称为非存活请求。

当我们谈到存活请求时，就是指维持系统和Web服务器间的网络连接。

因此，对于非存活请求，这些事务中的每一个均会在你的客户机和Web服务器间的建立起一个连接。你的请求从系统传送到Web服务器，而响应从Web服务器返回系统。最后，当该工作负载完成后，事务的处理和连接也就完成了。

因而，这个工作负载不仅仅可以用来测量Web服务器的性能，而且用于测量网络堆栈建立和断开连接的能力。这里，我们可以看到在路径长度方面，单个处理器提升了40%，而8个处理器则达到了120%。

所以 ，这是另一个有关典型8路商品系统的案例，在此案例中我们实现了2倍以上的容量和更高的吞吐量。还有一点值得提出的是，我们在此处所考虑的系统是很普通的8处理器系统。

虽然它们不是你今天可以得到的具备超高能力的系统，比如性能极佳的Xeon MP系统，但是这些系统非常适合于在工作现场，在你的实验室，以及在你的公司中从事Web服务器工作。

下面三张幻灯片将显示电子商务工作负载。如今，我确信你们都熟悉电子商务工作负载，因为你们在Web浏览器上在线购买物品时就会涉及到这些工作负载和事务。

通常，你会登录一个电子商务站点，比如Amazon.com或其它一些站点，然后进行登录，建立连接，获取信息，并将信息返回你的系统。而所有这一切，你都要求在安全的情况下进行。因此，这个工作负载利用了SSL。

即安全套接层，用于对请求进行加解密，为你的交易提供很好的安全性。所以在WebBench电子商务工作负载上，你可以看到单处理器的性能同样提高了30%，而8处理器则高达90%。

另一个电子商务工作负载是来自DocuLabs的NILE工作负载。现在，我们之所以对工作负载很感兴趣的原因是，我们喜欢在实验室中发掘客户在工作现场，在系统上所做的事情，从而可以在一个极好的受控环境中进行再现。

通过在受控环境中的再现，我们可以把握各种可以提高性能的机会，并根据需要予以实现。而且，我们可以对所做的改进进行检验。所以，NILE工作负载是另一个提供很好的静动态混合内容的电子商务工作负载。 你可以进行登录、浏览或数据库操作。这是一个非常现实的环境，你可以看到单处理器在性能的方面的重大提高，而8处理器工作负载的性能则提高的更多。

TPC-W是另一个事务处理委员会工作负载，主要针对在线书店等环境。真正地在某种程度上关注数据库是TPC-C和TPC-W的优点之一。

然而，TPC-W在这个问题上更加现实，走得更远，因为你不单单拥有数据库，即后端环境，而且有一个Inte.net层，通过它才能接近数据库。现在屏幕上是实际运作的不同网站的数量。

所以，这是一个非常现实的环境，非常有用的环境。这里的实际事务被我们称为每秒Web交互（Web interactions per second，WIPs）。每个WIP代表约10个请求。

你们又可以看到非常大的改进，不仅限于单个处理器的情况，我们看到其吞吐量增加了50%，而对于8处理器的系统，其性能较Windows 2000提高了两倍。

下面，我要稍微说一下ASP和ASP.NET脚本。ASP是在Microsoft Web服务器上提供动态内容最常见的方法之一。

在这些案例中，我们实际拥有14,000个ASP脚本和一个热设置，即约160个脚本，来处理60%的事务。我们之所以选取这些数目的脚本是基于对Microsoft网站的一份研究。

我们所要做的就是要看Microsoft网站的使用情况，从而可以在工作负载中得到有关使用情况的真实反映。所以我们对Microsoft网站进行了研究，并将这个研究继续下去，以更新该工作负载中的混合内容，从而真实地反映现实情况。

因此，这是一个非常现实的工作负载，我们称之为'大公司工作负载'（Large Corporate Workload）。这个工作负载拥有ADO和XML组件，而这里真正的实质问题是，如果你从Windows 2000上的ASP升级到Windows .NET Server 2003 中的ASP.NET，你就可以看到250%的吞吐量增长。

现在，ASP.NET可以用于Windows 2000了。因此，在这张幻灯片上，我们看到ASP和ASP.NET在该工作负载上的性能改进是不相同。

另外，在所有案例中，单处理器到8处理器的性能改进均是非常明显的，而这不仅仅体现在路径长度上，而且表现为实际可伸缩性的提高。

许多人要求我们改进静态Web主机。我们都知道到，耐心是美德。

如果你想在容量为2GB的Windows 2000系统上拥有10,000个站点，耐心确实是你必不可少的美德之一。因为每个网站的启动都需要你等候300秒，所以启动10,000网站就需要相当长的时间。

如果你要在Windows 2000上建立20,000个网站，恐怕是难以企及的事情。但是，通过Windows .NET Server 2000和IIS 6.0中的新模型和新的结构体系，静态Web主机比以前更具实用性。

对于那些希望自己托管Web站点而不是通过专门提供网站托管的公司来拥有站点的人，静态Web主机真的非常有用，现在已经有好几家这样的公司了。

现在，你可以在Windows .NET Server上拥有一个为20,000个，甚至更多的网站提供托管服务的系统，而且响应时间非常合理。请求的响应时间在1秒钟以内，也可能更短，而网站的实际启动时间仅为10秒钟左右。

因此，如果你将这个时间与Windows 2000的300秒相比较，你就可以看到Windows .NET Server 2003到底有了多大的改进。

下部分，我们将谈一谈文件服务器。

文件服务器在客户机和服务器方面都有了很多改进。根据NetBench工作负载的测量，内存管理，这是我们在前面已经讨论过的，和缓存算法的改进将吞吐量提高了140%。

NetBench工作负载很不错，拥有一个取自现实环境（如Microsoft总部）的混合负载，对Word等文档进行混合访问。我们还改进了NFS服务器。

所改进的方面包括：元数据缓存、分区和零复制。我们可以看到总体性能，根据Windows .NET NAS上SFS版本3的测量，提高了75%。人们不断要求我们改进ChkDisk，而我们也不停地对其进行改进。

另外有一点需要提到的是，我在这里所说的都是从Windows 2000到Windows .NET Server的改进。我们在以前，从Windows NT 4.0到Windows 2000就已经完成了许多重大的改进，包括对ChkDisk的改进。

现在，我们已经看到ChkDisk的性能提高了600%，其速度要比以前快得多。ChkDisk在这些方面的改进使我们可以在发生断电或诸如系统崩溃等情况而导致系统关闭时，真正地对系统上的磁盘进行扫描。

ChkDisk将启动并检查系统上的各个卷，确认需要修复的部分并进行修复。磁盘检查速度变快的原因与人们拥有的大型服务器有着特别的关系。现在，在发生崩溃或断电后，你可以比以前更快地启动系统。

这张幻灯片显示了NetBench工作负载的运行情况。现在，如果你看一下这张图表上所标示的代表Windows 2000的横条，你将看到当把处理器的数量增加到4个时，系统性能得到了很好的提高，但是超过8个处理器时，效果并不明显。

现在，通过Windows .NET Server 2003，我们可以很好地伸缩到8个处理器。事实上，我们最近在实验室中针对Itanium 2处理器所做的实验表明，超过8个处理器，系统的性能也可以得到很好的提升。因此，你们可以在这里看到，我们实际获得了高达每秒1.2Gb的NetBench吞吐量。

而如果你使用TOE或称为TCP/IP可卸载NIC，你可以获得每秒1.6Gb的吞吐量。TOE NIC属于全新的NIC，它将部分TCP/IP堆栈卸载到NIC，从而不需要由服务器来处理，节省了服务器上的空间和容量，让服务器可以比以前做更多的工作。

这个图表与前面向你们展示的TPC-C图表有些相似。我们在这里对NetBench在这些年的表现进行了简要的描述，首先从Pentium Pro双处理器系统开始。

在双处理器Pentium Pro系统中，你拥有100个文件服务器。今天，通过更先进的Pentium 3 Xeon 8处理器系统，你可以将这么多的文件服务器合并为8个。这样，在系统数量以及支持这些系统的软硬件上就可以节约一笔很大的开支。

如果你想进一步升级到Xeon MP或Itanium 2系统，你就有可能将所需的系统数目减少到4个。

在本例中提交页面的实际能力得到了巨大的提升，这不仅仅是因为实际硬件得到了升级和改进，而且是由于从Windows NT 4.0到Windows .NET Server 2003的升级使得服务器在客户机和服务器方面可以执行更多的工作。

所以，你可以有这样的想法：如果从Windows 2000升级到.NET Server 2003，你就可以获得很大的提升。如果你是从NT 4.0升级到Windows .NET Server 2003的话，你获得的系统改进将是非常巨大的。

下面，我将说一说Active Directory。

另外，我们在伸缩性和数据库方面对Active Directory进行了很多改进。数据库优化不但提高了整体伸缩性，而且缩小了数据库的体积。因此，我们可以以更快的速度做更多的工作。 你们当中许多人要求我们关注另一个关键的领域--复制，而我们在Active Directory中对其进行了巨大的改进以回应大家的请求。另外，Windows .NET Server 2003中添加了一个新的FastBind身份验证机制。

现在，我将向你们展示一张幻灯片，为你们提供一些极具吸引力的理由，来说明如果你仅在使用Active Directory的应用程序中需要身份验证，为何你要考虑使用FastBind。

正如我们前面说到的，通过IIS，用户状态堆栈和内存分配已经得到了重大改进，另外我们在Active Directory中拥有出色的性能诊断能力。

这是由MindCraft提供的DirectoryMark工作负载，是一个非常有趣的工作负载，面向为用户发送电子邮件和检查地址簿等事务。报文传送混合复杂基于电子邮件的发送操作，而寻址混合负载用于在地址簿中查找特定的联系人。

这里的数据库拥有一百万个条目，分散在10个组织单元中。事实上，我们看到，你可以获得巨大的性能提升，也许是伸缩性提高了6倍，通过报文传送混合负载将处理器从1负载作业的改进也令人吃惊，因为你将在一些地方看到我们可以把吞吐量提高32倍。这是大量工作的成果，而我们在Active Directory上下了最大的工夫。

下面，我将谈一谈LDAP基本搜索。这些搜索在我们在实验室的内部工作负载中拥有近两百万名用户中搜索包括用户名在内的5个属性。

我们可以看到相同的情况，Windows 2000上的文件服务器和IIS工作负载，在Windows 2000从4个处理器提升到8个处理器后，伸缩性只得到了很小的提高。

现在，我们已经转变了这种情况，我们看到伸缩性在从4个处理器增加到8个时得到了巨大的提高。因此，我们可以非常有效地在Windows .NET Server 2003上使用8个处理器。
这是一个LDAP子树搜索。形式上有点类似，但是正如8处理器的改进，它的改进要比你们所见过的，甚至是5个属性搜索还要大的多。

如果你看一下'简单绑定'（Simple Bind），一些验证机制，比如FastBind只验证机制可以在其中发挥作用。我们在简单绑定路径上获得了10%的提高，而在8个处理器上，这种提高则高达80%。

但是，如果你可以将FastBind仅用于身份验证，而许多应用程序只需进行身份验证，你可以获得4倍的性能提高。如果你静下心来思索，4倍的增长的确很让人吃惊。如果这样，你就可以真正地使用更少的系统，或者在已有的系统上使用更大的容量。

现在，如果你考虑到升级，我们可以看看，要是你考虑Windows 2000的话，其伸缩性，从1个处理器到4个处理器再到8个处理器，并不高。

现在通过Windows .NET Server，我们在伸缩性方面实现了从1个处理器到4个处理器的飞跃。而从4个处理器再到8个处理器，仍然可以实现伸缩性的提升。

因此，我们可以使用在实验室中用于分析和优化的内部工作负载，以这里所给的速度对用户的5个属性进行升级。

下部分，我将谈一谈终端服务。

由于我们真正地关注内存的使用，所以我们可以比以前更有效率地使用32位X86空间中的内存，终端服务器在容量上实现了重大的提升。

我们还花了很多时间，不仅针对数据库而且针对IIS、文件服务器、AD和终端服务器，对内存管理进行了改进。

看着这些工作负载，我们发现了内存管理中的某些瓶颈，接着我们有能力进入这些瓶颈来解决问题，同时改进了路径长度和可伸缩性方面的代码。在这里，我们有两个不同的终端服务器工作负载。

一个是'知识工人'（Knowledge Worker），类似于运行Excel、Outlook、Word和Internet Explorer的环境。另一个是'单任务工人'（Simple Task Worker），诸如在企业或公司前台使用计算机的员工，不管什么时候都只执行一个任务。

因此在终端服务器环境中，比起'知识工人'，我们可以在'单任务'中执行更多的事务，因为'单任务'是一个更简单的环境。但是，你可以看到终端服务器的实际容量得到了巨大的提高，增加了80%到140%。

这些巨大的进步与我们如何在内部针对主要的核心数据结构来管理内存，以及如何分布我们所必须使用的有限的32位虚拟地址空间有着必然的联系。

当然，在64位系统中，我们取得了很多方面的改进并获得了更高的性能，而随着我们得到更多64位应用程序，我们就有了非常诱人的理由来更多地考虑64位空间了。

下部分，我将谈一谈网络互联。

这是另一个你们经常在各种会议上，通过各种方式向我们提起的问题。你们常问，如何使系统更易使用和配置？我们解决这问题的一个办法是，提升系统体验。 Windows Server 2003在网络互联方面做得很好。我们可以更改TCP所使用的消息窗口的大小，其中的消息从用户传递到服务器，然后再返回到用户。在那里有一些管道窗口类型设置，我们可以根据媒体的速度加以调节。

所以，根据媒体速度，我们可以进行优化，不需要系统管理员通过调谐实际的混合负载来提高性能。此外，我们还提高了对各种网络适配器的自动调谐支持，而且我们有了具备更多卸载支持的新的Gigabit适配器。

Windows 2000支持芯片的各种特性。在Windows .NET Server中，我们有TOE和TCP/IP卸载，能够进行大型信息的发送。我们让网络适配器来分解和发送信息包，而且不需要在软件中进行处理。

我们还拥有其它一些将各种工作卸载到网络适配器的能力。现在，要是查看一下实际的网络堆栈，你们就可以发现我们将基准TCP、UDP和虚拟专用网络的性能提高了20%到25%。

由于这些改进是在低堆栈水平上获得的，从而反映在每个使用网络的人的身上。因此，任何使用网络的应用程序都会得到相同程度的性能提升。我们还在与我们的合作伙伴进行着许多改进Gigabit驱动程序的工作。

最后，如果你着眼于更高水准的网络和服务组件，比如Windows媒体服务器（Windows Media Server）、DNS和FTP，我们已经将Windows媒体服务器的性能提高了2到5倍。

一直以来，我们都对可测量和我们曾经见过的每一个环境进行伸缩性方面的改进。此外，如果你很关心64位系统，你肯定知道现在64位系统可以支持多达一百万个并发连接。这对于诸如聊天服务器等环境非常有用。

我们在 X86上所受的限制是，我们会用尽内核虚拟地址空间。在X86上，我们可以在一个已知系统上支持约100,000个并发TCP连接。

但是如果将连接数增加10倍，即一百万个连接，就需要在已知系统上拥有非常庞大的容量。当然，你可以通过在系统上增加内存来增加连接。 对于Windows媒体服务器，小组真的是倾尽全力，对整个服务器进行了重新设计，改进输入/输出和线程模型，减少磁盘访问，增加数据的智能预读取，实现流水化。

流水化就是让媒体，比如磁盘以很快的速度为系统提供数据，从而让你在显示有关信息时可以得到一切所需的信息。

当然，在媒体服务上，情况就大相径庭了，因为在许多案例中，如果不能消除假信号的干扰，性能将有所降低。我们在内容传输、缓存以及服务器上的多点传送方面都做了改进。

这张幻灯片显示了3个不同类型的情况，可能你们在使用媒体服务时就已经熟悉了。第一个是调制解调器拨号连接，从服务器到你，即用户的速度约为22 KBS。你们当中许多人拥有DSL或宽带连接。

根据我们在实验室中的测量，这个环境的连接速度为300 KBS。最终，你拥有了Internet或DVD一般的画质，就是1Mb，即1M字节的吞吐量。真真切切的1Mb。至于使用调制解调器的情况，你可以参看最顶端的图表。

我们对广播进行了很好的改进。类似于电视广播，服务器同时为每个人播送相同的节目，相当于实况广播。在满足对于硬件RAID和更简单的磁盘环境的需求方面，我们进行了重大改进。

你可以在这里看到Windows媒体服务中的重大改进提供了更高的吞吐量，使你可以更有效率地使用你的服务器。这里实际的衡量标准是看一台特定的服务能处理多少会话或通量。 这是一个高端服务器，2.4GHz双处理器系统配合4GBRAM。现在，如果你看一下最下方，每秒1Mb的数据流量，当你获得按需点播的高流量数据时，性能将大幅提高400%。

最后一部分，我将说一下服务器性能和诊断方面的内容。

对我来说，这真可以算是最有趣的一部分内容，因为在这里，你开始真正地了解系统的运行状况。现在，Windows性能小组有了各种各样很棒的工具，对吗？

对于环境来说，很好的一点是，你可以从任何需要的层面查看性能情况，真正地了解环境的状况。 比如总线分析，我们可以观察信息包在总线中的传输。

在处理器方面，我们可以了解处理器上所处理的事务类型，引起处理器停转的原因，以及诸如此类的情况。ETW是我们用于观察操作系统的一种方法。它对我们非常有用，我相信对你们也会很有用的。

这种方法非常吸引人的方面是，从最低的系统层面一直到最高的应用程序层面，我们都有事件与之相联系。因此，从这些不同的层面，你可以非常好地观察系统的运行状况。

从Windows 2000开始，我们就在操作系统中加入了ETW跟踪挂钩（hook）。我们有一套面向线程、输入/输出、分页和网络的核心OS挂钩。我们在Windows XP中添加了堆栈活动和上下文切换。

我们在Windows .NET Server 2003中加入了更多的上下文切换，而且我们还加入了新的IIS 6.0请求，让你可以更好地了解系统的运行情况。

由于需要介绍的信息太多了，我很难在这里进行描述，所以我提供了一张幻灯片为你提供更多详细的资料。从Windows 2000开始我们就已经有了Active Directory，其中的AD Perf套件可以真正地帮助你了解系统的状况。

我们在自己的系统内部使用这个套件来查看系统的状况。然后出现了'受管理环境'（Managed Environment），这个工具针对受管理应用程序拥有很高的性能跟踪分类能力。这是一个全新的工具，受管理代码和受管理环境将在未来变得非常的重要。

所以，对你们来说，这是一个面向未来的工具。

这是IIS诊断工具的简要示范。你们可以在左手边，'Contents'（内容）的下面，看到一些你们可以从系统获取的非常有意思而又不同的信息。

你可以查看响应时间的统计数字；你可以查看获得最多请求的站点；你可以查看图像的统计数字。事实上，我们已经在实验室中使用这个工具来查找由于某种原因被关闭了缓存或未按我们预想运转的站点。

右手方的'Summary'（总结）屏幕将显示CPU的使用情况和响应时间。可以帮助你获得单独的URL，即网页，了解其中的哪些是性能最好的，哪些使用得最为频繁，哪些在响应时间方面表现的最好，哪些的响应时间最长。

因此，你可以使用这些信息，真正地了解Web服务器的运行情况，很好地洞察你的计算机，把它从铁盒子转变为一个能以更有效地方式和你进行沟通的东西。

这里有一些有关特定网站的更多信息。我们可以知道获得最多请求和CPU使用率最高的URL。获得最多请求的URL也得到了最高的点击率，因此你就可以了解使用该网站的人们所最感兴趣的东西。

CPU使用率最高的URL具备了我们所称的改进机会。由于你知道了会消耗大量系统资源的URL，所以你可以花一些时间来大幅提高这些URL的性能。你得到了速度和很短的CPU使用时间。

现在，我要简单介绍一下我们已经谈过的伸缩性工作。当我谈到数据库性能的时候，我说的最多的是SQL Server。而当我们在谈论程序调度、内存管理和输入/输出方面的改进时，说的最多的则是数据库。

但是事实上，对于这个工作，即伸缩性方面的这些改进，是Windows开发小组、性能小组和许多其它Microsoft小组通过很好的协作共同为你提供的，对每个应用程序和每一台服务器都有帮助。

他们在操作系统中提供了非常好的特性以及更好的性能和可伸缩性，这些改进将帮助您在现在或未来更有效地对购买的硬件加以使用。

除了SQL Server，Oracle和DB2数据库都将实现这些改进。与Windows 2000相比，你将看到你在系统上所拥有的全套软件将以更高的效率运行于系统上。

而与NT 4.0相比，我们实现了更好的性能。为了满足大型系统的需要，我们现在可以支持真正的企业级系统。64个处理器、64位系统和高达512GB的内存将在未来得到更多的应用。

数据库性能和伸缩性都提高了2到3倍，而对于各种标准工作负载，比如符合工业标准的用来测量tpmC的TPC-C工作负载和用来测量QphH的TPC-H工作负载，我们都实现了重大改进。

因此，对于数据库，2倍的性能提高是非常普遍的。我们正在说的都是指32处理器系统。而对于其它服务器，比如Web服务器和文件服务器，我们所说的都是8处理器系统，也许还包括更大型的系统，特别是在64位空间里。

我们大力改进服务器以增加我们所能支持的高端企业级硬件。我们与我们的合作伙伴进行了很好的协作，不管是在现在还是在未来，都要为你带来振奋人心的系统。我们将继续致力于提高性能。

另外，补充一点，我认为有件事可能是最有意义的，那就是在Windows .NET Server 2003中，我们并没有让整个小组仅仅只关注性能和可伸缩性，我们还花了很多精力来提高安全性、可靠性和可管理性。

当我们对这三个Windows 操作系统的核心组件进行改进时，我们不仅仅在以前的基础上增强了性能，而且切切实实地让性能和伸缩性均得到了长足的进步。

原文转自：http://www.ltesting.net