针对 WAN 环境优化 Office SharePoint Server

项目
06/12/2012

本文内容：

设计 WAN 的拓扑结构
优化内容爬网过程
WAN 加速器和其他第三方工具
设计用于更快下载的网页
优化 WAN 环境的缓存

本文重点介绍如何优化 Microsoft Office SharePoint Server 2007 解决方案以在广域网 (WAN) 环境中获得更佳性能。

设计 WAN 的拓扑结构

您可以在 Office SharePoint Server 2007 服务器场中灵活配置服务器角色以进行优化，从而获得特定性能或达到可用性要求。在 WAN 环境中，了解服务器角色的几个技术特征很重要。除规划整体性能和可用性要求外，了解这些特征还可以帮助您优化 WAN 环境的服务器场拓扑结构。

优化爬网内容的拓扑结构

默认情况下，Office SharePoint Server 2007 会使用所有 Web 服务器对服务器场中的内容进行爬网。如果将服务器场配置为使用所有 Web 服务器进行爬网，索引服务器会向服务器场中的每台 Web 服务器发送请求。

对服务器场中的内容进行爬网会使 Web 服务器负载过大。这会导致网络流量达到峰值和出现拥堵，而且会占用大量的 CPU 和内存。对服务器场中的内容进行爬网所导致的网络流量可能会超出用户请求导致的网络流量。这种过高的网络流量可能对服务器场中所有 Web 服务器的性能产生负面影响，并因此增加对用户从 SharePoint 网站请求内容的响应时间。

在 WAN 环境中，我们建议您配置专门的 Web 服务器来对内容进行爬网，尤其是在要爬网的服务器场包含的内容超过 500 GB 或者要对 WAN 上的内容进行爬网的情况下。若要确保用户的请求不会受到内容爬网的影响，请从网络负载平衡的循环中移除专用 Web 服务器。这一点在全局环境中尤其重要，因为在这种环境中，区域服务器场的非高峰时间（您最有可能安排爬网作业的时间）与中央服务器场的高峰时间一致。

配置专用 Web 服务器以对本地内容进行爬网

为了在对服务器场的本地内容进行爬网时获得最佳性能，请将索引服务器配置为爬网专用的 Web 服务器，前提条件是索引服务器具有足够的内存容量，可同时用作索引服务器和专用的 Web 服务器这两个角色。

下图演示了使用专用的 Web 服务器进行了优化以编制内容索引的服务器场。

WAN 拓扑中的 SharePoint Server

如果将同一台服务器同时用作索引服务器和专用 Web 服务器，则在对内容进行爬网时，索引服务器就不必再向其他服务器发送请求。这样就可以提高爬网性能并减少网络上的总流量。如果无法做到这一点，可以使用服务器场中的其他服务器。

您可以使用下列任一方法将索引器配置为使用专用 Web 服务器：

在 SharePoint 管理中心配置 Office SharePoint Server 搜索服务。
直接编辑主机文件。

有关详细信息，请参阅以下资源：

配置专用 Web 服务器以对远程服务器场进行爬网

为了在对区域服务器场上的内容进行爬网时获得最佳的区域服务器场性能，请将中央服务器场上的索引服务器配置为使用区域服务器场上的专用 Web 服务器。

下图演示了两个区域服务器场，每个区域服务器场都使用专用 Web 服务器进行优化以编制内容索引。

在区域服务器场 1 中，有一台服务器专用于 Web 服务器角色。中央服务器场和区域服务器场 1 都使用这台专用 Web 服务器来对内容进行爬网。
区域服务器场 2 的配置与中央服务器场类似，Web 服务器角色也部署在索引服务器上。

针对 WAN 优化 Office SharePoint Server

请注意，中央服务器场中的索引服务器不使用中央服务器场中的 Web 服务器角色来对远程服务器场中的内容进行爬网。该索引服务器直接与远程服务器场中的 Web 服务器联系。

在上图中，如果在区域服务器场对内容进行爬网的同时，中央服务器场也在进行爬网，则使用区域服务器场 1 配置的性能会更好，具体表现在以下几个方面：

因为专用 Web 服务器位于一台单独的服务器上，所以区域服务器场 1 中的本地爬网性能得到改善。因此，中央服务器场不会影响索引服务器的性能。
减少了在 WAN 上的爬网时间。爬网所需时间更短的原因是：与 Web 服务器和索引服务器位于同一台服务器的情况相比，区域服务器场中的专用 Web 服务器响应更快。
因为中央服务器场中的索引服务器可与专用 Web 服务器互相通信，从而使中央服务器场的爬网过程得到改进。

如果要实现区域服务器场 2 所示的拓扑配置，可以计划区域服务器场和中央服务器场这两个场中的爬网过程使其不重叠，从而优化性能。

若要使用远程服务器场中的专用 Web 服务器对内容进行爬网，则必须直接编辑主机文件。确保在要对内容进行爬网的服务器场（而不是远程服务器场）中编辑主机文件。

在中央服务器场要对区域服务器场中的内容进行爬网的全局解决方案中，编辑主机文件，使要爬网的每个区域服务器场中的每个 Web 应用程序都有对应的项。主机文件中的每一项包括：专用 Web 服务器的 IP 地址，后跟 Web 应用程序的名称。例如：

10.10.10.4 TeamSites
10.10.10.4 MySites
10.10.10.4 Marketing
10.10.10.4 Sales

有关详细信息，请参阅通过编辑主机文件配置专用于爬网的前端 Web 服务器 (Office SharePoint Server 2007)。

优化查询性能

在 WAN 环境中部署 Office SharePoint Server 2007 时，用户的查询性能是关键考虑因素。在用户发布查询后，该查询会发送到 Web 服务器。Web 服务器与查询服务器通信以生成结果列表，然后与运行 Microsoft SQL Server 的计算机通信，以扩展结果列表，使其包含摘要文本、URL 和安全修整。

考虑到返回查询结果需要服务器之间的通信，您可以配置拓扑结构以优化查询性能。在服务器场中进行少量优化即可提高客户端计算机和服务器之间在 WAN 上的总体性能。

最重要的优化是使用专用 Web 服务器对内容进行爬网，如上一部分中所述。这样可确保 Web 服务器有能力处理用户请求，并且不会因索引作业过多而超载。

另外，可使用几种不同的方法来部署查询角色，每种方法提供一种不同类型的优化。每种方法都在以下两者之间取得不同的平衡：提供最佳查询请求服务和减少服务器场中的服务器之间在本地网络上的网络行程。下表汇总了这些配置方法并记录了每种方法的利弊。

配置	利弊
对所有 Web 服务器部署查询角色。	您可以在 Web 服务器上承载查询角色，以减少服务器场中服务器之间的往返通信。这样可优化查询性能。但是，因为两个服务器角色是在相同的服务器上承载的，所以如果大量使用这些 Web 服务器，则可能会影响这些服务器的整体性能。因此，请确保部署足够的 Web 服务器来处理高峰期间的用户请求。虽然这种配置可优化用户的查询性能，但缺点是位于服务器场的后端。索引服务器会将索引目录传播到服务器场中的每台查询服务器。如果查询角色部署在多台 Web 服务器上，则索引传播操作将需要更多的服务器资源。
使一台或多台服务器专用于查询角色。	通过指定一台或多台服务器专用于承载查询角色，可以优化这些服务器，使其使用所有可用资源来有效地执行该角色。这种配置通常还会减少查询服务器的部署数量。但是，这种配置需要在服务器场中的服务器之间进行大量的往返通信，以便处理来自 Web 服务器的查询请求，并在索引传播期间更新内容索引。
将查询角色和索引角色部署到同一台服务器。	您可以在同一台服务器上部署查询角色和索引角色。这种部署方式可优化服务器场通信，因为不再需要索引传播。但是，这种配置会将能够承载查询角色的服务器的数量限制为一台服务器。这是因为当查询角色部署在索引服务器上时，该索引服务器无法将内容索引传播到服务器场中的其他服务器。

对所有 Web 服务器部署查询角色。

您可以在 Web 服务器上承载查询角色，以减少服务器场中服务器之间的往返通信。这样可优化查询性能。

但是，因为两个服务器角色是在相同的服务器上承载的，所以如果大量使用这些 Web 服务器，则可能会影响这些服务器的整体性能。因此，请确保部署足够的 Web 服务器来处理高峰期间的用户请求。

虽然这种配置可优化用户的查询性能，但缺点是位于服务器场的后端。索引服务器会将索引目录传播到服务器场中的每台查询服务器。如果查询角色部署在多台 Web 服务器上，则索引传播操作将需要更多的服务器资源。

使一台或多台服务器专用于查询角色。

通过指定一台或多台服务器专用于承载查询角色，可以优化这些服务器，使其使用所有可用资源来有效地执行该角色。这种配置通常还会减少查询服务器的部署数量。

但是，这种配置需要在服务器场中的服务器之间进行大量的往返通信，以便处理来自 Web 服务器的查询请求，并在索引传播期间更新内容索引。

将查询角色和索引角色部署到同一台服务器。

您可以在同一台服务器上部署查询角色和索引角色。这种部署方式可优化服务器场通信，因为不再需要索引传播。

但是，这种配置会将能够承载查询角色的服务器的数量限制为一台服务器。这是因为当查询角色部署在索引服务器上时，该索引服务器无法将内容索引传播到服务器场中的其他服务器。

除对单个服务器场优化查询性能外，还有几种用于优化多服务器场方案的方法：

在父服务器场为子服务器场提供搜索服务的服务器场间共享服务方案中，通过在父服务器场上部署专用的查询服务器，父服务器场能够处理子服务器场中的搜索查询，而不影响该父服务器场上其他用户选项的性能。在服务器场间共享服务的情形下，子服务器场中的 Web 服务器直接与父服务器场上的查询服务器和数据库服务器联系，而不是通过父服务器场上的 Web 服务器进行通信。请注意，在 WAN 上不支持服务器场间共享服务，在这种服务中，父服务器场为子服务器场提供服务。但是，大型组织可能包括一个中心网站，在该网站中父服务器场提供服务，子服务器场提供网站和内容。在这种情况下，可以将父服务器场配置为对地理位置分散的多服务器场环境中的区域服务器场上的内容进行爬网，而不会影响中心网站中为中心网站的用户提供网站和内容的子服务器场的性能。
在中央服务器场对区域服务器场的内容进行爬网的多服务器场地理分布式环境中，可以通过以下方式配置服务器来优化内容爬网和查询性能：
- 在所有服务器场中，在索引服务器上部署 Web 服务器角色。从网络负载平衡循环中移除该服务器，并将父服务器场爬网过程配置为使用该专用 Web 服务器对内容进行爬网。
- 在每个服务器场上的所有负载平衡的 Web 服务器中部署查询服务器。

从地理上分离服务器场服务器

服务器场中的服务器之间的通信需要稳固的网络连接，以适当处理用户请求并避免性能瓶颈。标准的网络要求是，服务器场中的所有服务器都位于同一局域网 (LAN) 上的同一数据中心。不支持跨 WAN 链接分离服务器场中的服务器。

除该指导外，还有一些特定的要求允许一台或多台 Web 服务器与服务器场中的其余服务器位于不同的地理位置。在这种情况下，Web 服务器位于不同的数据中心，但与运行 SQL Server 的计算机连接到的 LAN 相同。

备注

下面的指导代表一个以前未记录的部署方案的可支持性要求。

该方案的指导是一些初步指导，在进一步测试后可能会发生更改。在提供正式的、经过测试的指导之前，您可以使用该指导提供的一组规则进行测试和部署。可使用这些规则作为在您自己的环境中进行测试的基础，并确定您自己的质量和性能阈值。

该方案获得了合理的商业支持。如果在您自己的环境中的进一步测试或结果表明该方案会引起重大问题，则必须将 Web 服务器移到更靠近数据库服务器的位置（如果此操作可以解决问题）。

当满足以下条件时，则该部署方案可满足初步可支持性要求：

Web 服务器和数据库服务器之间的网络链接的延迟时间小于 1 毫秒 (ms)。若要获得这一延迟，Web 服务器与数据库服务器的理想距离应不超过 16 千米。在最佳网络配置下，161 千米的距离可获得小于 1 毫秒的延迟，但这种情况很少见。如果距离在 16 到 161 千米之间，请咨询您的网络和硬件提供商，看看他们能否提供小于 1 毫秒延迟的服务级别。不支持服务器场相隔超过 161 千米。在测量承载同一个服务器场的服务器的两个数据中心之间的延迟时，使用 Ping 工具来测量从远程数据中心的 Web 服务器到主数据中心的数据库服务器的延迟。然后将往返时间结果除以 2。
链接上有足够的可用带宽来处理 Web 服务器与服务器场中的其他服务器之间的通信。
参与共享服务的所有服务器角色与数据库服务器位于同一数据中心。这包括索引角色、查询角色和 Excel Services 角色。
服务器场中的所有服务器计算机都在同一网络段上。在数据层没有路由器切换（按原义，物理层连接这些服务器）。即使路由器和交换机之间的网络连接速度非常快，路由器和交换机也会增加延迟时间。
如果 Web 服务器所处理的负载类型是用户浏览请求的一部分，那么 Office SharePoint Server 2007 将可以接受 Web 服务器和数据库服务器之间的一些延迟。另一方面，包含许多或自定义 Web 部件、Stsadm 命令和搜索爬网的页面的延迟时间可能更长一些。
服务器场中的服务器不能跨时区。必须将服务器场中的所有服务器计算机同步到同一时区。

优化内容爬网过程

计划和配置爬网过程的方式会影响性能和可靠性。可以对以下过程进行优化，以改进在 WAN 上的爬网过程：

协调内容源的爬网。
配置爬网频率并协调完全爬网和增量爬网。
配置爬网设置。

协调内容源的爬网

在中央服务器场通过 WAN 链接对区域服务器场上的内容进行爬网的全局环境中，规划内容源很非常重要，因为这些内容源代表可以计划和管理的内容单位。

当需要执行以下操作时，请添加搜索内容源：

对不同类型的存储库进行爬网。
按照与其他计划不同的计划对某些存储库进行爬网。
限制或增加要爬网的内容量。

以上每个原因都是在优化对 WAN 上的内容进行爬网时考虑的因素。至少要为每个区域服务器场创建一个不同的内容源。这使您能够基于服务器场的本地非高峰时间和维护日程安排来对每个区域服务器场计划爬网。

此外，基于以下条件为单个区域服务器场创建不同的内容源：

为爬网次数较频繁的内容（如协作内容）或不太频繁的内容（如已发布内容）创建单独的内容源。
为定期发布的内容创建单独的内容源。例如，如果您知道一组特定网站的内容仅在星期五更新，则可以创建单独的内容源使爬网计划与内容更新同步。
基于在区域服务器场的非高峰期间可对 WAN 链接爬网的内容量来创建内容源。例如，如果您的目标是每周对大型存储库进行一次爬网，则可以将该存储库划分成五到七个可在夜间成功进行爬网的内容块，然后将这些爬网作业错开到每周的各个时间段。
为 Office SharePoint Server 2007 网站外部的内容创建单独的内容源。在 Office SharePoint Server 2007 和 Windows SharePoint Services 3.0 中，更改日志会记录更改的对象，包括访问控制列表 (ACL) 的更新。通过更改日志，可以仅对已更改的内容进行增量爬网，从而大大减少了重新爬网内容源所需的时间。不能对存储在外部源中的内容进行增量爬网。因此，应单独管理这些内容源的爬网过程。有关详细信息，请参阅更改日志(https://go.microsoft.com/fwlink/?linkid=106007&clcid=0x804)。

有关规划爬网和内容源的详细信息，请参阅规划内容爬网 (Office SharePoint Server)。

配置爬网频率并协调完全爬网和增量爬网

如上一部分中所述，创建单独的内容源的主要原因是方便按照不同的计划对内容进行爬网。在具有长时间延迟的跨 WAN 链接上对内容进行爬网的环境中，这一点尤其重要。在计划区域服务器场的爬网作业时，请考虑以下因素：

区域服务器场上的计划停机和高峰使用期。
更改或更新内容的频率。
带宽可用性和 WAN 链接的延迟。请务必考虑使用 WAN 链接的其他进程。

对于 Office SharePoint Server 2007 和 Windows SharePoint Services 3.0 中的每个内容源，您可以指定一个执行完全爬网的时间和一个执行增量爬网的时间。请注意，您必须先对某个特定内容源运行完全爬网，然后才能运行增量爬网。如果对尚未执行爬网的内容选择增量爬网，系统将执行完全爬网。

在为 WAN 环境规划爬网计划时，请考虑采用下列最佳方案：

将爬网计划的时间错开以便按时间交错使用 WAN 链接，使 WAN 链接不致饱和。
仅在必要时安排完全爬网。建议执行完全爬网的频率要低于增量爬网的频率。
将每个内容源的增量爬网安排在承载内容的服务器可用并且对服务器资源的需求较低时执行。
Office SharePoint Server 2007 和 Windows SharePoint Services 3.0 中的一些管理更改（例如，应用 Service Pack 或还原数据库）会在下一个定期预定爬网期间自动触发一个完全爬网。将那些需要完全爬网的管理更改安排在紧挨着计划的完全爬网时间的前面发生。例如，我们建议您将创建爬网规则工作安排在下一个预定完全爬网之前，这样，就不需要另外的完全爬网。有关需要完全爬网的管理更改的详细信息，请参阅规划内容爬网 (Office SharePoint Server) 中的“执行完全爬网的原因”。

重要说明：
应用 Microsoft Office Server 的基础结构更新后，未来的更新和还原数据库操作将不会自动触发完全爬网。因此，当应用未来的更新或还原数据库时，搜索功能将继续根据爬网规则定义的常规时间表进行爬网。有关详细信息，请参阅规划内容爬网 (Office SharePoint Server)。

除了这些适用于各个区域网站中的爬网内容的最佳方案之外，请确保中央服务器场的整体爬网计划不会超出索引服务器的能力。请根据索引服务器执行爬网的能力来执行同时爬网。索引服务器和承载内容的服务器的性能决定了爬网可以相互交迭的程度。随着时间推移，您可以逐渐熟悉每个内容源的典型爬网时段，从而可以制定用于安排爬网的策略。

有关规划爬网和内容源的详细信息，请参阅规划内容爬网 (Office SharePoint Server)。

配置爬网设置

您可以针对 WAN 环境优化多个特定的爬网设置，以增强爬网作业的可靠性。可使用下列设置：

搜索的超时设置
爬网程序影响规则

搜索的超时设置

服务器场管理员可以指定在连接到其他服务时希望服务器等待的时间，以及服务器等待内容请求得到确认的时间。如果您添加在 WAN 链接上爬网的内容源，请根据该链接的总体延迟时间主动增加超时设置。您可以根据 WAN 链接上爬网内容的实际性能随时调整超时设置。

可按照以下过程为 Office SharePoint Server 搜索服务指定超时设置。

指定超时设置

在管理中心的“应用程序管理”选项卡上的“搜索”部分中，单击“管理搜索服务”。
在“管理搜索服务”页面上的“服务器场级搜索设置”部分中，单击“服务器场级搜索设置”。
在“管理服务器场级搜索设置”页面的“超时设置”部分中，执行下列操作：
- 在“连接时间(秒)”框中，键入希望服务器在连接到其他服务时等待的秒数。
- 在“请求确认时间(秒)”框中，键入希望服务器等待另一服务确认要连接到该服务的请求的秒数。
单击“确定”。

爬网程序影响规则

爬网程序影响规则提供一种控制每次请求和爬网的文档数目的方法。通过爬网程序影响规则，管理员可以控制爬网作业对 WAN 链接产生的影响。

对于每项爬网程序影响规则，您可以指定一个 URL，或在 URL 路径中使用通配符以包含该规则所适用的一组 URL。然后，您可以指定可对指定的 URL 同时发出多少个页面请求，或者选择每次仅请求一个文档并在两个请求之间等待您所选的时间（秒）。

在初始部署期间，请将爬网程序影响规则设置为尽可能高效地使用 WAN 链接，同时仍要对大量的内容进行足够频繁地爬网，以确保已爬网内容的新鲜度。稍后，在操作阶段，您可以依据自己的经验以及爬网日志中的数据来调整爬网程序影响规则。

可以按照以下过程添加爬网程序影响规则。

添加爬网程序影响规则

在管理中心的“应用程序管理”选项卡上的“搜索”部分中，单击“管理搜索服务”。
在“管理搜索服务”页面上的“服务器场级搜索设置”部分中，单击“爬网程序影响规则”。
在“爬网程序影响规则”页上，单击“添加规则”。
在“添加爬网程序影响规则”页面上的“网站”部分的“网站”框中，键入将与此爬网程序影响规则关联的网站名称。

备注

键入 URL 时，不得包含协议。例如，不要包括 http:// 或 file://。
在“请求频率”部分中，选择下列选项之一：
- 一次最多请求指定的文档数，并且在两次请求之间不等待。如果您选择此选项，请使用“同时请求数”列表来指定在对此 URL 进行爬网时，您希望爬网程序一次请求的文档数。可以指定 Office SharePoint Services 搜索服务在对此 URL 进行爬网时一次发出的最大请求数。
- 一次请求一个文档，并在两次请求之间等待指定的时间。您可以指定在对此 URL 进行爬网时两次请求之间的延迟（秒）。选择此选项时，Office SharePoint Server 搜索服务一次向每个网站发出一个请求，然后等待指定的时间，之后再发出下一个请求。在“等待时间(秒)”框中，键入两次请求之间的等待时间（秒）。两次请求之间的最短等待时间为 1 秒，最长时间为 1,000 秒。
单击“确定”。

有关爬网程序影响规则的详细信息，请参阅下面的文章：

管理爬网程序影响 (Office SharePoint Server 2007)。
估计搜索环境的性能和容量要求中的“爬网程序影响规则”。

WAN 加速器和其他第三方工具

本部分介绍使用以下类别的第三方解决方案优化 WAN 环境的选项：

WAN 加速器
卸载和缓存设备
客户端解决方案
数据复制、多主机同步和配置管理
多服务器场可管理性和报告
字节级复制或基于硬件的复制

因为每个环境都是不同的，所以建议不要采用特定的合作伙伴解决方案。此外，合作伙伴解决方案可以不同的方式应对机遇。因此，每个解决方案都有不同的优势。根据环境的特定需求以及合作伙伴解决方案的相关优势来评估各个解决方案，这一点很重要。

有许多合作伙伴的解决方案都可增强或优化 Office SharePoint Server 2007 解决方案。若要获取最新的合作伙伴列表，请参阅 Microsoft Office System 解决方案目录（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=108591&clcid=0x804)（该链接可能指向英文页面）。

WAN 加速器

WAN 加速解决方案已经推出了很长一段时日。最短路径算法和数据包压缩工具已经推出了数十年。最近几年的最大创新是优化 TCP/IP 堆栈和服务器消息块 (SMB)。

大多数 WAN 加速器都是成对运行的，其中一个设备安装在运行 SharePoint 产品和技术的服务器旁边的数据中心中，另一个设备安装在分支机构中。这两个设备通过使用缓存、压缩、差异化和专有的方法来优化在两个设备间发送的数据包。无论这些设备为嵌入式设备还是只是升级了缓存的网络设备，方法是相似的。各个合作伙伴解决方案侧重于优化网络堆栈中不同的层。

选择网络加速器时需要考虑的两个重要条件包括：

贵组织的安全要求。诸如 IPsec 或 HTTPS 的要求将影响这些选择。
贵组织所使用的应用程序。如果您需要的设备还提供 Microsoft Exchange Server 优化以及文件共享流量，这也会影响您的选择。

示例解决方案包括：Cisco、Citrix、Packeteer、Riverbed 和 F5。

卸载和缓存设备

尽管 SharePoint 中的缓存技术可以减少不必要的后端流量，但提供卸载和缓存设备的合作伙伴可帮助缩短跨度，包括客户端与服务器之间的 WAN 连接。

如果您通过 Internet 承载您的 SharePoint 网站，并且您的目标是优化网络流量并减少点击服务器的请求数量，则卸载和缓存设备可以起到重要作用。有很多合作伙伴将这些解决方案用于优化 Internet 上公开内容的承载过程。此空间中使用的策略包括缓存和相关的专有技术，具有不同算法的卸载式压缩，预热和预取以及各种购物车技术。某些合作伙伴擅长于向特定类型的客户端（例如公用电话亭、全球网吧中的计算机或其他未正确连接的轻薄型设备）安全高效地传送内容。

此外，合作伙伴还在 Internet 领域提供全局缓存和网络优化传送技术以减少丢弃数据包。例如，一些解决方案可优化网络流量以便仅将客户端请求中的增量发送到服务器。这些类型的解决方案可减少 WAN 流量，还会加快页面返回速度，在这些页面中，客户端与服务器之间或其他中间设备之间的往返通信次数已经减少。

与 Microsoft ISA 相似，一些解决方案提供卸载验证或委派验证作为访问信息的网关。这些解决方案会添加额外的安全层。为了满足多个要求，需要寻找提供防火墙、负载平衡以及用于卸载和缓存的某些智能的产品或解决方案。预计将来会看到这些类型的功能的更广泛整合。

示例解决方案包括：Cisco、F5、Inktomi、Microsoft ISA Server 和 Microsoft Internet Application Gateway。

客户端解决方案

某些合作伙伴侧重于优化客户端体验，而不是解决网络和服务器基础结构。诸如预取、后台同步、压缩、广告拦截器和图像筛选器之类的技术可极大地提高在 Internet 上检索内容的性能。如果文本是主要目标并且您可以在没有图像的情况下进行管理，情况更是如此。

存在多个允许用户与 SharePoint 网站自动同步的客户端应用程序。客户端开始与某个网站同步之后，客户端应用程序在后台中的客户端计算机上（或当客户端联机时）自动缓存该网站的内容。例如，当用户单击某个文档时，该文档在本地已可用，并且该用户不受 WAN 链接影响。同样，当用户添加或更新文档时，客户端应用程序负责同步对联机网站所做的更改。这些客户端应用程序通常负责管理出现的任何冲突并允许用户来决定如何解决这些冲突。

某些客户端对此情况的处理好于其他客户端。某些客户端仅对文件提供支持。某些应用程序同时对列表和文件提供支持。您可能找不到脱机 Wiki，但是您可以找到 RSS 阅读器以在本地或脱机时查看大多数列表。例如，除了与文档库同步之外，Office Outlook 2007 这个客户端就允许您通过 RSS 阅读器，使用 RSS 来脱机查看 SharePoint 博客或列表。Office Groove 2007 还提供良好的脱机体验，并且可以通过 WAN 提供对等协作和文件压缩功能。有关 Microsoft 客户端解决方案的详细信息，请参阅使用 Office Outlook 2007 和 Office Groove 软件扩展 Office SharePoint Server 全局解决方案。

此领域的合作伙伴侧重于优化诸如 WAN 链接影响性能或客户端频繁脱机的用户体验。缓存（本地副本）、压缩以及将同步转移到后台进行，都让您感觉好像就在 LAN 服务器上。如果您选择向用户提供客户端应用程序，请确保向他们提供足够的培训，以便他们能够尽可能高效地工作。

合作伙伴：Colligo。Microsoft：Microsoft Office Outlook 2007、Office Groove 2007

数据复制、多主机同步和配置管理

无论是由于两个办公室之间的 WAN 链接过慢，还是由于具有多主机要求的灾难恢复要求，在部署规划中通常都需要进行复制。SQL Server 2005 提供日志传送和数据库镜像以进行灾难恢复或网站故障转移。但是，当您要求可同时提供读取/写入访问的两个单独的服务器场时，需要合作伙伴来提供解决方案。

某些合作伙伴解决方案包括类似于 WAN 加速器的服务器缓存。如果 WAN 链接失败，该解决方案可继续在远程网站的缓存中提供内容。另一些合作伙伴擅长于在网站断开连接很长一段时间之后同步数据。例如，入海后到达码头的船只可以与中心网站同步。

某些合作伙伴可扩展 SharePoint 产品和技术接口以配置对数对 Web 应用程序、网站集或列表的复制。

备注

产品团队尚未在 WAN 环境中测试 Office SharePoint Server 2007 的发布功能。发布功能可在从中央服务器场到只读环境中的发布内容中提供某个值。但是在没有获得测试结果的情况下，我们无法提供此方案的特定指导。

合作伙伴解决方案包括：Syntergy、WinApp Technologies、Casahl 和 Infonic。

多服务器场可管理性和报告

在包含多个服务器场的全局部署中，跨服务器场和网站管理设置可能非常困难。一些合作伙伴提供的工具可以简化配置设置的管理、权限管理、有效的用户权限和内容元素（例如母版页和内容类型）的管理。如果您决定将多个服务器场部署到您的环境中，请考虑使用有助于管理多个服务器场和大量网站的合作伙伴工具。

某些合作伙伴侧重于在各服务器场和多个环境中帮助您配置设置。例如，SharePoint 跨网站配置器（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=108592&clcid=0x804)（该链接可能指向英文页面）就是 Microsoft 设计用于配置审核、有效期限、母版页和内容类型，以实现多个 Web 应用程序间一致性的工具。

合作伙伴解决方案包括：Quest Software、echoTechnologies、IDevFactory、AvePoint、CorasWorks、Barracuda Tools、CommVault 和 Symantec。

字节级复制或基于硬件的复制

提供基于硬件的复制或字节级复制的合作伙伴使故障转移和同步数据中心之间的环境变得非常容易。在实现共享磁盘（如存储区域网络 (SAN)）时，共享磁盘会变成一个故障点。硬件供应商使用各种方法提供冗余通道、冗余光纤、冗余磁盘和各种阵列配置。不同的解决方案可提供不同级别的容错能力。

如果要消除硬件作为故障源的可能性，请评估 Microsoft 群集服务 (MSCS)。MSCS 提供了基于硬件的容错能力。基于软件的故障转移解决方案（如 SQL 日志传送和 SQL 镜像）可提供硬件容错能力，但当与 SharePoint 产品和技术一起使用时，故障转移不是自动执行的。

在某些情况下，实施在堆栈中提供较低级别复制的解决方案可满足特定的业务需求。字节级复制可创建主要环境的克隆或镜像，还可以创建故障转移到的辅助环境。连续的字节级复制可提供一种自动或手动故障转移方法。

在评估这些类型的复制解决方案时，需要注意的一个重要方面是了解服务器的名称、Web 应用程序的名称和帐户在配置数据库中是硬编码的。这意味着在不同名的另一台服务器上复制的服务是无效的。如果复制环境中的服务器名称仍与主环境中的服务器的名称相同，则这些类型的解决方案是有效的。无论是哪种解决方案，如果一种工具提供的复制超出了应用程序的认识范围，则必须测试该工具以确保它在故障转移的环境中可以使用。

合作伙伴解决方案包括：Neverfail 和 Double-take。

内置于硬件中的解决方案（如基于 SAN 的复制）包括：HP、EMC Centera 和 Hitachi Data Systems。

设计用于更快下载的网页

在网络容量有限的环境中，简化您的网页并使它们尽可能小并且尽可能及时作出响应。有多种不同的技术可实现此目标，其中的大多数技术并非特定于 SharePoint 产品和技术。本部分不详细讨论可在任意网站上使用的一般方法，而侧重于了解 SharePoint 产品和技术中包含的功能，页面中包含的内容以及可加快 SharePoint 网站的初次访问速度的方法。

页面元素

SharePoint 网站上的页面由多个唯一元素组成，如下图所示。

使用控制重叠的 SharePoint 网站页

在呈现该页面时，它会包含母版页、布局页和该页面内容。页面内容包括每个页面字段的值，而且还包括许多其他元素（例如主题、样式表、图像和导航）。下表演示了 SharePoint 网站的单个页面中显示的文件和流的示例。此示例捕获了在初次访问协作门户网站的默认主页时发出的所有 HTTP 请求。

URL	大小（字节）
http://myServer/_layouts/images/topnavhover.gif	96
http://myServer/Pages/Default.aspx	1656
http://myServer/Pages/Default.aspx	1539
http://myServer/Pages/Default.aspx	66084
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://myServer/_layouts/images/blank.gif	43
http://myServer/_layouts/images/helpicon.gif	1025
http://myServer/_layouts/images/Menu1.gif	68
http://myServer/_layouts/images/titlegraphic.gif	1299
http://myServer/_layouts/images/gosearch.gif	19933
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://myServer/_layouts/images/whitearrow.gif	68
http://myServer/_layouts/images/recycbin.gif	1004
http://myServer/PublishingImages/newsarticleimage.jpg	10710
http://myServer/_layouts/images/icongo01.gif	1171
http://myServer/_layouts/images/menudark.gif	68
http://myServer/_layouts/images/topnavhover.gif	96

请注意以下事项：

下载该页面共需要 29 个请求。
总页面大小是 235 KB。
这表示初始网页加载；请求中的几乎所有项目都具有指示浏览器不要在一年内再次加载这些项目的缓存指令。第二个和后续页面加载仅生成三个请求。其中，两个是进行的 NTLM 协商的一部分，所以实际仅下载了一个项目，即该页的 HTML。
使用默认的 IIS 压缩级别 0，此压缩级别尽可能使压缩量达到最少。额外再进行压缩会使下载大小更小。
加载的不同文件类型中包括：
- 4 个 .axd 资源请求
- 4 个 .css 资源请求
- 12 个图像资源请求
- 6 个 .js 资源请求（其中几个是重复的）
- 对 default.aspx 的 3 个页面资源请求（其中两个是 NTLM 协商的一部分）

这些文件类型中的大部分都是非常明显的，可能的例外情况是 .axd 资源类型。.axd 资源是 ASP.NET 2.0 版中新功能的一部分。开发人员可以将某个资源（例如脚本文件或样式表）添加到某个控件中。在该控件中，开发人员使用 ClientScript 类以包含名为 GetWebResourceUrl 的方法。在运行时呈现该控件时，它会动态生成该资源的 URL。该资源自身会被编译为控件程序集，所以此方法会提供使该资源流出该程序集并流向客户端的方法，就好像该资源是位于 Web 服务器上的单独文件。

了解页面使用的资源请求可帮助您了解应用优化的位置和方式。您可以使用各种不同的工具和方法来度量此类信息。对于本文，使用了一个称为 Fiddler（该链接可能指向英文页面）的免费软件工具。Fiddler 可以在客户端工作站上运行并可跟踪对页面发出的所有 HTTP 请求。然后，该工具会在网格中显示结果，如下图所示。

SharePoint 网站的 Fiddler 结果

当您更改网站以对其进行优化时，请使用 Fiddler 对其进行测试。要最准确了解正在请求哪些项目、正在对哪些项目进行缓存以及每个项目的大小，请按下列步骤操作：

删除浏览器所有临时文件。
启动 Fiddler。
请求您的页面。

备注

确保通过单击链接来请求该页面。如果您只单击“刷新”按钮，系统会自动再次请求项目，且不会准确反映所做的任何优化更改。

优化页面下载

了解页面的组合后，可以使用不同的方法来优化该页面的下载体验。通常，目标是最大限度地减少客户端计算机和服务器计算机之间的往返数，并减少通过网络的数据量。本文中的指南包含一些建议，这些建议可广泛应用到 SharePoint 产品和技术的各种不同实现过程。

请记住，查看这些建议和查看可能开发的任何其他自定义优化有重要区别。将页面优化方法分为两个类别之一：第一个页面请求和后续页面请求。第一个页面请求的优化是第一次请求页面时实现的那些种类的优化，但不一定影响后续页面请求。后续页面请求优化是指那些可以改进用户体验的优化，而与用户是第一次还是第 50 次请求该页面无关。关键是您需要针对获得的增益来平衡功能损失。如果仅在第一次用户点击网站时实现增益，则与功能损失相比，优化可能是不值得的。

BLOB 缓存

二进制大型对象 (BLOB) 缓存将在下文中进行更加详细的论述。简单地说，二进制大型对象 (BLOB) 缓存可用于将缓存指令应用到 SharePoint 产品和技术中存储的页面上的项目。如果包含这些缓存指令，浏览器将不会尝试再次下载这些项目，直到该缓存项目到期。如上一个主页示例所示，协作门户网站模板的默认主页中包含的几乎所有项目都具有与这些项目关联的缓存指令，这就是不针对后续页面点击请求这些项目的原因。有关设置和配置 BLOB 缓存的更多详细信息，请参阅下文中的优化 WAN 环境的缓存。

IIS 压缩

IIS 压缩也在本文的优化 WAN 环境的缓存部分中进行了更详细的论述。但是，如前面所述，默认设置将使用压缩级别 0。您应尝试不同的压缩设置级别，直到找到一个进行优化压缩时对 Web 服务器的 CPU 影响最低的压缩设置级别。实际上在几乎所有情况下，您都可以使用大于 0 的压缩级别。但是，请切记该压缩级别仅适用于动态文件（例如，.axd 和 .aspx 文件）。

64 位硬件

服务器场中的硬件选择也可能影响请求延迟。32 位系统对于每个应用程序具有 2 GB 的 RAM 的内存限制。尽管您可以将应用程序支持扩展到 3 GB 的 RAM，但 SharePoint 产品和技术不支持使用 /3GB 开关。在内存不足的情况可能会对请求延迟产生负面影响，表现在以下方面：

如果内存量受限，会导致回收 SharePoint 应用程序池，还将强制回收 ASP.NET 应用程序域，这会导致响应用户请求时的延迟时间延长。
内存不足的错误可能导致 BLOB 缓存停止提供内容服务。

通过使用 64 位硬件，可确保您可分配并使用足够的 RAM 来防止这些错误。

Web 园设置

Web 园设置也可能会不经意地导致 BLOB 缓存运行不一致。因为仅一个进程可以获得管理缓存所需的锁，所以成功使用缓存取决于哪个线程对请求提供服务。如果没有 BLOB 缓存锁的 Web 园对请求提供服务，则 Web 园发送的响应内容将不具有与该 Web 园关联的缓存指令。这样会增加请求数和在网络上发送的数据量。因此，如果您打算使用 BLOB 缓存，就不应使用 Web 园。

最大限度地减少页面上受保护的项目

当用户向 SharePoint 产品和技术进行验证时，会出现两个行为。第一，系统验证凭据以确定用户身份。第二，角色提供程序枚举用户所属的 SharePoint 组的列表。每次请求页面时，将再次调用角色提供程序以枚举用户所属的所有组。

但是，这种调用组成员身份的情况可在单个页面上发生多次。例如，当您转到主页时，默认协作门户网站模板页需要两次调用角色提供程序：其中一次针对该页面本身，另一次针对此该面上的图像。SharePoint 库中存储的和位于该页面上的每个图像将强制额外调用角色提供程序以验证权限（即使所有图像都存储在同一图像库中）。无论将这些图像添加为页面上的字段（即页面内容的一部分）还是将这些图像添加到网站的母版页，都将进行该验证。

针对有限带宽或高延迟的环境开发的网站应设计为最大限度地减少页面上使用的图像数目。很多网站使用几个图像作为母版页的一部分，以创造不同的视觉效果。因为延迟将随着安全检查次数的增加而增加，所以设计针对这些环境的网站时应使用尽可能少的图像。

最大限度地减少图像数目和大小

如前面部分中所述，您应该最大限度地减少网站中的图像数目。若要帮助进行该工作，可以将多个图像嵌入到单个文件中，然后在页面中引用单个图像。不仅文件下载大小将减小，而且文件数目减少也会减少网络流量。使用此技术创作页面较复杂，但是，如果每个往返和文件大小非常重要，此技术可证明是帮助提高性能的非常有用的方法。下图演示了包含多个图像的单个图像文件的示例。

一行中的 6 个图标图像

下图演示了此图像随后将如何更改以作为表中的单个图片显示。

一个表中的 6 个图标图像

图像的处理完全通过样式表类进行。在每个表格单元格中的 div 和 img 元素中使用了两个主要类。这些类如下所示：

.cluster {

height:50px;

position:relative;

width:50px;

}

.cluster img {

position:absolute;

}

每个图像都具有与其关联且基于其标识符 (ID) 的类。该样式可剪切图片并定义与群集中初始图片的偏移量。这些类如下所示：

#person {

border:none;

clip:rect(0, 49, 49, 0);

}

#keys {

clip:rect(0, 99, 49, 50);

left:-50px;

}

#people {

clip: rect(0, 149, 49, 100);

left:-100px;

}

#lock {

clip:rect(0, 199, 49, 150);

left:-150px;

}

#phone {

clip:rect(0,249, 49, 200);

left:-200px;

}

#question {

clip:rect(0, 299, 49, 250);

left:-250px;

}

表格的 HTML 包括带有相应 ID 值和类名的 div 和 img 标记，如下所示：

<table border="1">

<tr>

<td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

</tr>

<tr>

<td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

<td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

</tr>

</table>

多个 Microsoft Web 属性和产品现在都使用此技术，包括 Microsoft Passport 网络和 Microsoft Office Outlook Web Access (OWA)。MSN 小组已进行了一些性能测试以分析更改产生的影响，并发现第一页的加载时间缩短了 50% 到 75%。

如果您正在 Microsoft Office SharePoint Designer 2007 中创作页面，则有一个重要方面需要考虑。在 Office SharePoint Designer 2007 中新建页面时，该程序会自动将以下 XHTML 架构标记添加到该页面中：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

如果您使用此架构，图像将不会正确对齐。您必须从 HTML 标记中移除 xmlns 属性，以便按预期方式显示图像。

延迟下载 core.js

Office SharePoint Server 2007 中包含的主客户端脚本文件名为 core.js。它是最大的脚本文件，未压缩时大约为 257 KB，压缩后大约为 54 KB。在某些情况下，您也许能够延迟下载 core.js。在延迟下载时，页面呈现速度更快，因为直到在浏览器中打开了该页面，core.js 文件才开始下载。这样用户就可以更快地查看该页面并开始阅读内容。此技术在具有匿名用户的 Internet 方案中最有用。相反，对于诸如“网站操作”菜单这样的功能或用户界面元素，已验证用户需要在加载页面时下载 core.js。

可以使用以下步骤来实现此技术。

创建一个不使用 core.js 的自定义布局页。此布局页将与主页一起使用，这样初次访问网站的用户将无需等待即可立即下载 core.js。新布局页需要与现有主页兼容，因此新布局页应与当前正在使用的布局页具有相同的相关内s容类型。

备注

默认情况下，在协作门户网站中指定欢迎页面内容类型。
向页面添加以下标记：<SharePointWebControls:ScriptLink runat="server"/>。这将指示系统不使用 core.js，除非它被引用。
创建一个自定义控件来检查已验证用户。该控件非常简单，并且主要包含下面的代码（用 C# 显示）：
```
if (HttpContext.Current.Request.IsAuthenticated)   
    Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
```
在每个 Web 服务器上，将该控件放入全局程序集缓存 (GAC)，然后在将使用该控件的 Web 应用程序的 Web.config 文件中为该控件添加一个 SafeControl 项。
将该自定义控件添加到在步骤 1 中创建的自定义布局页。

向该布局页添加 IFRAME。该 IFRAME 应引用具有以下内容的页面：

<body>
<SharePoint:ScriptLink name="core.js" runat="server" />
<script language="javascript">
 DisableRefreshOnFocus();
</script>
</body>

签入该自定义布局页并发布该页面。
以新的布局页为基础创建网站主页。

执行上述步骤后，请测试网站的主页以验证它是否正常工作。首次访问的匿名用户不应在网页源代码中看到对 core.js 的引用，它应在浏览器缓存中结束。

此外，在使用此技术前应考虑下列事项：

网站母版页和系统母版页不能相同；否则，_layouts 中的所有页面将无法正常工作。
确保该母版页不包含任何在加载时需要 core.js 才能正常运行的控件。
确保该母版页不包含任何加载或引用 core.js 的 ScriptLink 控件。

有关其他详细信息和示例代码，请参阅 Microsoft 企业内容管理 (ECM) 团队博客（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=106008&clcid=0x804)（该链接可能指向英文页面）。

优化列表视图网页

Microsoft 服务小组已致力于量化并缩短列表视图网页的呈现时间。列表视图网页是每个列表和库用于支持内容浏览的 AllItems.aspx 页。根据视图中显示的列数和列的格式，该页面的呈现时间可能会大不相同。例如，显示选项和启用状态图标可显著影响呈现时间。呈现折叠组的时间远远多于展开组，但这两种组都比不分组要慢。

由于存在这些细微差别，因此仔细考虑视图在列表视图网页中的构造方式（尤其是通过慢速网络链接时）非常重要。处理包含大量数据的列表时，应仔细调整所有视图（尤其是默认视图）。通常情况下，可以通过以下方式缩短列表的呈现时间：

减少显示的列。
排除包含状态信息的任何列。
使用链接（但不包含编辑菜单）查看项目的详细信息。

下表介绍可缩短呈现视图所需时间的自定义设置。

项目	说明
视图类型	将视图创建为数据表视图（而不是标准视图）。
视图：项目限制	项目数超过 1,000 的任何视图的呈现速度都可能很慢。使用慢速连接时，尝试找到一次显示的数据量和查看所有数据所需的往返次数之间的最佳平衡很重要。一次显示的行数越多，往返次数就越少，但页面会越大。
视图：筛选器	使用 [今天] 和 [我] 可依据新鲜度或工作分配筛选项目。使用“状态”字段可只在默认视图中显示活动项目。
视图：列	使用尽可能少的列。创建一个默认视图，其中极少数列允许用户通过高级浏览进一步查看。

下表介绍将增加视图呈现所需时间的自定义设置。每个其他列都会稍微增加呈现时间：对于使用快速网络连接、包含 1,000 个项目的列表来说，每列呈现时间多达 0.5 秒。某些列需要的时间更多，如表中所示。

项目	说明
分组依据	分组会添加 HTML 和 JScript，降低大型列表的呈现速度。使所有组在默认情况下折叠实际上会进一步增加呈现时间，因为这样需要对浏览器对象模型执行其他操作。
列 – 链接到带编辑菜单的项目	选项“链接到带编辑菜单的项目”呈现时间最长；类似的选项“链接到项目”不会明显增加呈现时间。
列 – 查找带状态的用户	添加带状态的用户查阅字段会为每个链接添加 HTML 以打开状态菜单。此外，它还使用带宽来确定状态可用性。

下表介绍对呈现视图所需时间影响相对较小的自定义设置。

项目	说明
排序、汇总	应用多个排序和汇总将显著增加呈现时间，但对于包含 1,000 个项目的列表来说，每个视图的呈现时间通常需要不到一秒。

优化 WAN 环境的缓存

Office SharePoint Server 2007 中有许多不同的缓存选项。其中一些选项旨在提高呈现管道中的吞吐量—从服务器收到请求到响应开始流回客户端计算机这一段时间。尽管这是网站整体性能的重要方面，但本部分重点介绍与以下内容相关的缓存：

客户端缓存上服务器配置的角色。
控制通过网络从服务器传输到客户端的项目的大小。

BLOB 缓存

BLOB 缓存是仅适用于 Office SharePoint Server 2007 发布功能的机制。这使得 BLOB 缓存对基于协作门户网站模板的公司门户网站和基于发布门户网站模板的面向 Internet 的网站来说是理想的选择。通过 BLOB 缓存，您可以配置与发布网站列表（如页面库和网站集图像）提供的项目相关的缓存指令。当客户端计算机上的浏览器遇到缓存指令时，它会检测要检索的项目是否可保存到本地，以及在缓存指令到期前，是否不需要再次请求。在地理位置较分散的环境中，BLOB 缓存至关重要，因为它可减少通过网络请求和发送的项目数。

打开 Office SharePoint Server 2007 中的 BLOB 缓存时，会出现两个不同行为。首先，每次请求可缓存项目时，Office SharePoint Server 2007 都会搜索收到该请求的 Web 服务器的硬盘驱动器，以查看本地是否存在副本。如果存在，则该文件会直接从本地磁盘流到用户。如果该文件不在本地磁盘上，则会在存储该项目的 SQL 数据库中制作该项目的一个副本，然后将该项目发送到发出请求的用户。从那以后，该项目的所有请求都可直接从 Web 服务器获取，直到该项目的可缓存性值指示它已过期。那样会通过降低数据库服务器上的争用，而使服务器场获得更好的性能。

另外一个行为是，在将项目发送至客户端时向该项目追加一个可缓存性标头。此标头会指示浏览器应将该项目缓存多长时间。例如，当某图像的可缓存性值为 3 天时，如果在接下来的 3 天内再次请求该图像，则浏览器将使用本地缓存中该图像的副本；而不会再从服务器请求该图像。

测试网站以查看所缓存的项目以及这些项目的缓存方式时，您可以使用 Fiddler（该链接可能指向英文页面）(http://www.fiddlertool.com)（该链接可能指向英文页面）。下面的屏幕快照显示了用于发布的简单 SharePoint 网站上的一个 Fiddler 捕获。该网站是使用默认协作门户网站模板创建的。页面上添加了一些其他文本内容，母版页上添加了多个图像。

Fiddler 工具结果

Fiddler 应用程序中包含了几条重要信息。

左侧的 # 列显示从浏览器到服务器发出共计 44 个呈现页面的请求。
“结果”列显示从该项目请求返回的 HTTP 结果代码；结果为 200 表明已成功检索该项目。
URL 列显示正请求哪些项目。
“正文”列显示每个项目的大小。
“缓存”列显示与每个项目相关联的缓存指令。“缓存”列中的数据显示几个项目具有与自身相关联的缓存指令；即这些项目具有一个大于 0 的 max-age 属性。缓存指令以秒为单位来表示。这意味着，对于演示的页面，有多个项目被配置为缓存 365 天（60 秒为一分钟，60 分钟为一小时，24 小时为一天，应为 60x60x24 = 86,400x365 = 31,536,000）。

请注意，带有该缓存指令的这些项目都位于 _layouts 目录中。这些项目具有该缓存设置是由 _layouts/images 虚拟目录在 IIS 中的配置方式确定的。当您新建一个 Web 应用程序时，Office SharePoint Server 2007 会自动创建映射到 Web 服务器物理磁盘上的文件夹的多个虚拟目录。当它创建 _layouts/images 虚拟目录时，它会添加一个适用于整个目录的缓存指令。下面的屏幕快照显示 IIS 管理器管理单元中的目录的配置。

图像文件夹的 IIS 管理器属性

因为所有那些项目都有一个与其关联的非零缓存指令，所以下次请求该页面时，浏览器会使用其本地浏览器缓存中的该项目的副本（而不是再次从服务器请求）。下面的屏幕快照显示再次请求该页面时的 Fiddler 的快照。

Fiddler 工具结果

如 Fiddler 数据显示，请求的项目数显著减少（从 44 减少为 11）。需要注意的一个重要方面是，根据页面的请求方式，发出的请求数可能会不同。如果您使用浏览器中的“刷新”按钮，则无论是否存在该项目的本地缓存版本，都可能将再次请求所有项目。相反，如果通过使用链接或快捷方式导航到页面来请求该页面，则仅请求未缓存的项目。

该 Fiddler 数据中显示的另一内容是该浏览器正在向服务器发出一个请求，以获取母版页上本地缓存中已有的其他图像；响应代码 304 表明了这一点。这意味着浏览器已经对某个项目发出一个条件请求。响应 304 意味着服务器上的版本未根据客户端上的版本修改，所以不需要再次下载。即使文件不是通过网络下载的，它仍会生成一个到服务器的往返，以确定本地副本是最新的。在地理位置比较分散的环境中，服务器往返的成本很高，所以应尽可能减少往返次数。如果向剩余的每个项目（该页面除外，它始终由服务器返回）添加一个非零的缓存指令，则可以实现此目标。BLOB 缓存功能可添加此缓存指令。

您通过将 Web.config 文件用于将在其中使用缓存的 Web 应用程序来配置 BLOB 缓存。在文本编辑器（如记事本）中打开 Web.config 文件并搜索 BlobCache 项。默认情况下它将是：

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

在 BlobCache 元素中使用的属性具有下列含义：

location 指 Web 服务器硬盘驱动器上将存储缓存项目的位置。
path 应缓存的文件类型的正则表达式。
maxSize 允许缓存使用的大小（以 GB 为单位）。
enabled 设置为 true 可启用 BLOB 缓存。

对单个项目设置缓存到期值还需要下面的属性（默认情况下不包含）：

max-age 项目应在客户端计算机上缓存的时间（以秒为单位）。

通过将 max-age 属性设置为一个非零值，可缓存项目有一个与其相关联的缓存到期值，以便浏览器不必再下载该项目，甚至验证它是否具有最新版本。例如，假定您希望启用缓存，并在 Web 服务器上分配多达 100 MB 的空间来存储项目。这些项目应每天到期一次，并且除缓存的预定义类型外，还应缓存 .htc 文件。为满足这些要求，应指定以下 BlobCache 属性：

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

请注意，必须在服务器场中的每台 Web 服务器上对 Web.config 文件进行此项更改。大多数情况下，BLOB 缓存将立即开始工作，但最安全的做法是，在实现这些更改时使用 iisreset 命令。下面的屏幕快照显示在只启用 BLOB 缓存时（如上文所述），以前显示的同一页面请求的 Fiddler 数据。

Fiddler 工具结果

请注意，/SiteCollectionImages 库中的所有项目现在都具有 HTTP 状态代码 200，该值指示这些项目已成功下载。此外，这些项目现在都有一个与其关联的缓存指令，指定这些项目不会在一天（8,400 秒）内到期。如果再次请求该页面，则 Fiddler 会显示没有再次请求任何图像；因此该页面具有的服务请求数从 44 下降为 3，并且其中的 2 个是从 Web 服务器和客户端应用程序之间进行的 NTLM 身份验证协商发出的。下图显示再次请求该页面时的 Fiddler 数据。

Fiddler 工具结果

此外，在处理 BLOB 缓存时，请注意以下事项：

还需要配置其他一些方面，因为您需要在每个 Web 服务器上更新 Web.config 文件。但是，获得的好处值得您的付出。
检查您的网站内容并确定是否还应该从缓存提供任何其他文件类型。.htc 文件就是一个很好的示例。因为多数发布网站中都使用 .htc 文件，所以您应该将该文件类型添加到要缓存的文件类型列表中。
BLOB 缓存只能处理 SharePoint 库中存储的项目；它不能用于缓存其他源的内容。
默认情况下，匿名用户无法使用某些列表。如果有匿名用户访问该网站，则需要手动为以下列表配置权限，才能缓存其中的项目：
- 母版页样式库
- 样式库

使用 BLOB 缓存时，还需要注意其他两个配置选项。第一个选项是清除 BLOB 缓存。如果要清除特定网站的缓存，请导航到该网站集，并单击“网站操作”>“网站设置”>“修改所有网站设置”菜单。在网站集管理任务列表中，单击网站集对象缓存链接。在“重置基于磁盘的缓存”中，选中“强制此服务器重置其基于磁盘的缓存”框，然后单击“确定”按钮。

如果正在考虑在 SharePoint 场中使用 Web 园，则还需要注意，这样做将导致 BLOB 缓存以似乎不一致的方式运行。在一个服务器场中配置多个 Web 园时，它会引发问题，因为只有一个 Web 园可以获得管理 BLOB 缓存所需的锁。因此，可能出现 BLOB 缓存只间歇性工作的情形，而使用 BLOB 缓存的成功与否取决于提供请求服务的线程。

IIS 压缩

现在，当您安装 SharePoint 产品和技术时，IIS 压缩会自动打开，这一点与早期版本的 SharePoint 产品和技术不同。一些用户点击网站后，就可以验证该压缩是否工作，方法是查看 Web 服务器上的 %WINDIR%\IIS Temporary Compressed Files 目录。该目录应该包含多个文件，指示静态文件已被请求，IIS 已压缩这些文件的副本并将这些副本存储在本地驱动器上。再次请求该文件时（无论是否为同一用户），会直接从此文件夹提供该文件的压缩版本。也可以压缩动态文件，但动态文件始终是实时压缩的；不会在本地 Web 服务器上保存副本。

压缩可以显著节约带宽。例如，每个 SharePoint 页面中都包含 core.js 文件。当该文件未压缩时，它是 257 KB；而压缩后，在不执行其他 IIS 压缩微调的情况下，该文件只有 54 KB。应在用户第一次访问该网站之后缓存 Core.js，但此示例演示在低带宽情况下，压缩如何显著改善带宽使用情况。

安装 SharePoint 产品和技术后，安装程序会配置 IIS 以压缩静态文件类型 .htm, .html 和 .txt；它将压缩动态文件类型 .asp 和 .exe。检查您的实现中广泛使用的文件类型后发现，压缩更多文件类型可能会很有用。例如，可能有必要压缩静态文件类型 .css 和 .js 以及动态文件类型 .axd 和 .aspx。

若要将静态或动态文件类型添加到将压缩的类型列表中，请使用 adsutil.vbs 文件（默认情况下，该文件位于每个 Web 服务器上的 %SystemDrive%\Inetpub\AdminScripts 文件夹中）。下面的示例演示 Microsoft Windows Server 2003 如何在压缩静态文件类型列表中包含 css 和 js 文件：

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

下面的示例演示如何在动态文件类型列表中包含 .aspx 和 .axd 文件：

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

更改压缩的文件类型时，请确保只包含适合压缩的文件。例如，.jpg 文件并不适合压缩，因为该文件格式本身已经过压缩。此外，2007 Microsoft Office 系统文件类型（如 docx、xlsx 和 pptx）也不适合压缩，因为这些文件不会直接从服务器提供，而是通过不同的 ISAPI 筛选器传送，这些筛选器用于管理 Microsoft Office 内容的丰富、全面的最终用户体验。此外，在 2007 Microsoft Office 系统中，这些文件类型本身已经过压缩。

除控制压缩的文件类型外，还可以控制用于动态文件类型的压缩级别。可以使用的压缩级别范围是 0 到 10。压缩级别越高，文件将越小。但缺点是，压缩级别越高，消耗的 CPU 就越多，因此若要创建较小的文件，您用于压缩的 CPU 使用率就越高。当启用 IIS 压缩时，会将其配置为使用压缩级别 0。过去，SharePoint 产品和技术的理想压缩级别为 9。若要更改压缩级别，请使用上文所介绍的 adsutil.vbs 脚本文件。下面的示例演示如何将压缩级别更改为 9。

CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

备注

此设置不会更改静态文件的压缩方式。

有关详细信息，请参阅使用 HTTP 压缩 (IIS 6.0)（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=108705&clcid=0x804)（该链接可能指向英文页面）。

将 BLOB 缓存与 IIS 压缩相结合

通过启用 BLOB 缓存，可以显著减少在用户浏览 SharePoint 网站时服务器的往返次数和通过网络发送的文件数。将压缩与 BLOB 缓存结合使用时，还会减少发送至客户端的文件流量。结合使用这两种功能可显著减少网络流量以及对网络和服务器资源的争用。

下载此书籍

本主题包含在以下可下载书籍内，以方便您阅读和打印：

Office SharePoint Server 2007 的规划和体系结构 - 第 2 部分（该链接可能指向英文页面）

有关可下载书籍的完整列表，请参阅 Office SharePoint Server 2007 的可下载书籍。

另请参见

概念

为 WAN 环境优化自定义 Web 部件
 使用 Office Outlook 2007 和 Office Groove 软件扩展 Office SharePoint Server 全局解决方案
 支持的 Office SharePoint Server 全局解决方案

通过

针对 WAN 环境优化 Office SharePoint Server

设计 WAN 的拓扑结构

优化爬网内容的拓扑结构

配置专用 Web 服务器以对本地内容进行爬网

配置专用 Web 服务器以对远程服务器场进行爬网

优化查询性能

从地理上分离服务器场服务器

优化内容爬网过程

协调内容源的爬网

配置爬网频率并协调完全爬网和增量爬网

配置爬网设置

搜索的超时设置

指定超时设置

爬网程序影响规则

添加爬网程序影响规则

WAN 加速器和其他第三方工具

WAN 加速器

卸载和缓存设备

客户端解决方案

数据复制、多主机同步和配置管理

多服务器场可管理性和报告

字节级复制或基于硬件的复制

设计用于更快下载的网页

页面元素

优化页面下载

BLOB 缓存

IIS 压缩

64 位硬件

Web 园设置

最大限度地减少页面上受保护的项目

最大限度地减少图像数目和大小

延迟下载 core.js

优化列表视图网页

优化 WAN 环境的缓存

BLOB 缓存

IIS 压缩

将 BLOB 缓存与 IIS 压缩相结合

下载此书籍

另请参见

概念

其他资源