调整 Web 服务器性能 (Office SharePoint Server)

本文内容：

• 体系结构

• 优化

通过使用本文中有关物理体系结构和优化的建议做法，您可以帮助改善 Web 服务器的性能。

体系结构

本节包含有关配置、拓扑以及要为 Microsoft Office SharePoint Server 2007 服务器场中的 Web 服务器考虑的其他方面的信息。

对 Web 服务器使用 64 位服务器

我们强烈建议您在 64 位操作系统上的 64 位 Office SharePoint Server 2007 上安装 Web 服务器，除非您有足够的业务理由不这么做。

仔细配置 32 位服务器

如果您必须运行 32 位 Web 服务器，请遵循下列建议：

• 不要对 32 位系统使用 /3gb 开关。 如果您运行的是 32 位 Web 服务器，对于所有用户模式进程，我们建议您不要在 Windows Server 2003 中使用 /3gb 开关将 2 GB 的虚拟地址空间更改为 3 GB。我们不建议使用 /3gb 开关的原因是，多数 SharePoint 网站通信都涉及通过操作系统发送大量数据。因此，仅为操作系统留下 1 GB 的地址空间可能会破坏计算机的稳定性。有关详细信息，请参阅以下 Microsoft 知识库文章：Windows SharePoint Services 2.0（或更高版本）或 SharePoint Portal Server 2003 SP2（或更高版本）中不支持 Windows Server 2003 /3GB 开关 (https://go.microsoft.com/fwlink/?linkid=105919&clcid=0x804)。

• 混合使用 32 位和 64 位服务器会影响负载平衡。您可以运行这样一个环境：有些 Web 服务器运行 32 位版本的 Office SharePoint Server 2007，而有些服务器则运行 64 位版本。但是，这样会存在一个风险：如果网络负载平衡器配置为使用不太智能的模式（例如轮循机制），则 32 位 Web 服务器可能会过载。建议您将负载平衡器配置为基于负载管理分配。

  此外，如果同时部署 32 位和 64 位服务器，将会增加服务器场的维护开销。这是因为必须要单独跟踪和管理这两种体系结构的第三方应用程序、自定义解决方案、修补程序和软件更新。

不要使用 Web 园

Web 园是由多个工作进程提供支持的 Internet Information Services (IIS) 应用程序池。建议不要为企业内容管理网站使用 Web 园。这是因为 Web 园会对页面输出缓存产生负面影响。

对具有许多活动工作流的系统考虑使用其他资源

在具有许多活动工作流实例的系统中，请考虑为运行 SQL Server 2005 的计算机添加更多 RAM、更多 Web 服务器和更多资源。

为未向最终用户公开的服务使用专用 Web 服务器

专用 Web 服务器是未连接到向最终用户公开的负载平衡器的 Web 服务器。建议您使用专用 Web 服务器来运行任何昂贵的服务，例如：

• 搜索索引

• 管理中心

• 配置文件

• Excel Services

只打开您需要的功能

Office SharePoint Server 2007 提供了许多功能。如果您只打开与用户相关的功能，则资源将可以得到更有效地利用。有关关闭功能的信息，请参阅使用功能(https://go.microsoft.com/fwlink/?linkid=105337&clcid=0x804)。

对具有极高使用率的服务器场使用 Kerberos 身份验证

如果在给定时间单位内，您需要处理服务器场中的大量请求，那么建议您使用 Kerberos 身份验证，前提条件是这样做符合您的其他业务需求。因为 Kerberos 身份验证使用缓存，所以它可以快速返回身份验证请求结果。

优化

本节包含有关配置、最终用户培训、维护以及用于优化现有 Office SharePoint Server 2007 服务器场的其他建议的信息。

监控 SQL Server 性能

最好按堆叠顺序自下而上来监控性能和容量，因为数据库服务器上的压力可能会导致 Web 服务器上出现压力。例如，如果运行 SQL Server 的服务器花费很长的时间来响应来自 Web 服务器的请求，而 Web 服务器按典型速率接收来自最终用户的请求，则 Web 服务器上的请求将开始加入队列。这种行为最终会导致看起来像是 Web 服务器性能不佳的情况，但实际上与数据库服务器相关。

对于 ，请确保监控 SQL Server 索引碎片，并遵循用于 SharePoint 产品和技术的 SQL Server 碎片整理准则，可以在以下 Microsoft 知识库文章中找到这些准则：如何对 Windows SharePoint Services 3.0 数据库和 SharePoint Server 2007 数据库进行碎片整理 (https://go.microsoft.com/fwlink/?linkid=105588&clcid=0x804)。这样做可以显著改善搜索时间。

应用 ASP.NET“引发的 GC 的数目”计数器修补程序

当您运行基于 Microsoft .NET Framework 2.0 版构建的 Microsoft ASP.NET 2.0 Web 应用程序（例如 Office SharePoint Server 2007）时，“引发的 GC 的数目”性能计数器的值增加得非常快。此外，CPU 使用率会变得很高，并且计算机性能将降低。若要解决此问题，请应用以下知识库文章中提供的修补程序：修补程序：当您运行基于 .NET Framework 2.0 构建的 ASP .NET 2.0 Web 应用程序时，“引发的 GC 的数目”性能计数器的值增加得很快，并且 CPU 使用率变得很高 (https://go.microsoft.com/fwlink/?linkid=105921&clcid=0x804)。

配置应用程序池回收设置以提高可用性

请使用本节中的指南来优化应用程序池以提高可用性。

• 如果服务器场中有多台 Web 服务器，请确保将应用程序池设置为不同时间在每台 Web 服务器上进行回收。

• 在不同时间回收 IIS 网站以将负载分摊到服务器场中的所有 Web 服务器。如果您需要同一时间在特定网站上回收多个应用程序池，则应该通过负载平衡器临时移除该 Web 服务器，以避免在回收过程中造成性能不佳的情况。

• 在 32 位服务器上规划应用程序池回收时，请考虑每个应用程序池使用的内存量，并根据使用的内存量修正回收的频率。与使用较多内存的应用程序池相比，使用较少内存资源的应用程序池所需的回收将较少。

  64 位服务器的内存管理比 32 位服务器的内存管理更有效。但尽管如此，建议您还是为 64 位服务器安排在夜间进行应用程序池回收。这样可帮助降低出现由碎片导致出现问题的可能性。

有关应用程序池回收的详细信息，请参阅重叠的回收和 SharePoint：什么是 64 位设置？ (https://go.microsoft.com/fwlink/?linkid=127018&clcid=0x804)（该链接可能指向英文页面）。

监控和管理 32 位工作进程回收

默认情况下，将为每个 32 位 Windows 用户模式进程分配 2 GB 的虚拟地址空间。此地址空间的一部分必须保留为未使用，以供动态分配。此外，Office SharePoint Server 中的某些操作需要使用很大的连续地址空间块来执行动态分配。进程运行的时间越长，地址空间中的碎片就越多。出于此原因，当 Office SharePoint Server 工作进程的大小超过 1.2 GB 到 1.4 GB 时，进程将开始出现内存不足错误以及其他异常事件。随着进程继续消耗地址空间，错误将变得更加严重，并最终导致进程被 IIS 终止。

重要说明：
在 64 位环境中，运行时进程回收的默认值通常已足够。因此，不建议您更改这些值。

为了解决此问题，建议您在每台 32 位 Web 服务器上设置以下过程。

• 使用 IIS 重叠的回收

  通过定期重新启动工作进程，可以帮助减少地址空间中的碎片。这将使进程更加稳固和有效。可以使用 IIS 中重叠的回收功能来正常回收 SharePoint 工作进程。这将使现有用户请求有时间完成。在停止并重新启动现有进程之前，将启动一个获取所有新请求的新进程。当全部现有请求得到满足或者超过了关闭时间限制时，旧进程将关闭。

  为了获得最佳效果，您应将 IIS 设置为在特定时间进行回收，以及在内存使用量达到特定级别时进行回收。

  • 将基于虚拟内存的回收配置为在内存使用量达到 1700 MB 时发生。

  • 将使用内存的回收配置为在内存使用量达到 1000 MB 时发生。

  • 将关闭时间限制至少设置为 300 秒，以便让长时间运行的用户请求（例如大文件上载）有机会完成。

  • 对于在一天中的某些时段有规律地出现高负载的环境，请使用基于时间的回收。将计划的回收设置为大约在峰值流量开始前 30 分钟进行。

  如果未能在 32 位服务器上配置这些设置，则可能会对 ASP.NET 缓存管理产生负面影响。如果未设置进程内存限制，ASP.NET 将为您计算该限制。如果用户模式地址空间为 2 GB，则 ASP.NET 将使用 60% 物理 RAM 或 800 MB，二者中取较小值。此值将用于确定缓存应按怎样的力度清理内存。将此值设置得太低可能会导致太多次内存清理操作，而设置得太高则会使进程变得太大，并导致 OutOfMemory 异常和其他错误。

  有关回收工作进程的详细信息，请参阅在 IIS 6.0 中回收工作进程 (https://go.microsoft.com/fwlink/?linkid=105924&clcid=0x804)。

• 启用 LogEventOnRecycle IIS 元数据库属性以跟踪进程回收

  若要跟踪工作进程的回收频率，您可以使用 Internet Information Services (IIS) 6.0 元数据库中的 LogEventOnRecycle 属性在系统事件日志中生成条目。如果发现这些进程的回收频率高于每 4 小时一次，请考虑增加更多的 Web 服务器来处理负载。

  可使用 Adsutil.vbs 来设置标志。若要将所有应用程序池进程的原因写入事件日志，请执行以下步骤：

  1. 单击“开始”，单击“运行”，键入“cmd”，然后按 Enter。

  2. 切换到 Adsutil 所在的目录。默认目录位置如下：%SYSTEMDRIVE%\Inetpub\AdminScripts

  3. 键入以下命令，然后按 Enter：

     cscript adsutil.vbs Set w3svc/AppPools/ <您的应用程序池名称> /LogEventOnRecycle 255

     在此命令中，将您的应用程序池名称 替换为希望在其上启用事件的应用程序池的名称。

     备注

     如果应用程序池名称中有空格，例如，“SharePoint- 80”，您必须在命令中元数据库路径的两边使用双引号，如以下示例中所示。

     cscript adsutil.vbs Set "w3svc/AppPools/SharePoint - 80/LogEventOnRecycle" 255

  有关详细信息，请参阅如何修改 IIS 6.0 中的应用程序池回收事件(https://go.microsoft.com/fwlink/?linkid=105925&clcid=0x804)。

在非高峰期间执行维护

如果在正在使用其他网站时移动或删除网站，将可能使整个门户失去响应。因此，请在非高峰期间执行这些类型的资源密集型维护活动。

不要使网页保持为签出状态

如果在使用企业内容管理，请不要使网页保持为签出状态，而是要尽可能快地在每次更改后签入网页。将网页保持为签出状态会降低网页呈现性能。

仔细监控对自定义设置和 Web 部件的使用

仅部署遵循下列资源中描述的最佳做法的自定义设置：

• 最佳做法：使用可处置的 Windows SharePoint Services 对象（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=105945&clcid=0x804)（该链接可能指向英文页面）

• 在 Windows SharePoint Services 3.0 中使用代码的开发工具和技术（第 1 部分，共 2 部分）

• 最佳实践：使用 SharePoint 对象模型时的常见代码问题(https://go.microsoft.com/fwlink/?linkid=105946&clcid=0x804)

• SharePoint 产品和技术自定义策略（白皮书）(https://go.microsoft.com/fwlink/?linkid=105947&clcid=0x804)

同时，请监控 Web 部件和网页呈现时间。同事 Web 部件会占用大量的处理资源。因此不要在呈现大量其他信息的网页上使用该部件。

监控和管理大文件

在处理大于 5 MB 的文件时，请将文档的最大上载大小更改为符合业务需求的最大预期文件大小。文件的默认最大上载大小为 50 MB。SharePoint 产品和技术支持的最大文件大小为 2 GB。

如果有一个最终用户经常访问的大文件集合，并且这些文件很少更新，建议您将这些文件存储在 Office SharePoint Server 外部。或者，请考虑使用脱机协作客户端。

培训最终用户如何使用大文件

最终用户使用大文件的方式可能会对性能产生重大影响。

• 所有最终用户都至少应为 Internet 临时文件（Internet Explorer 缓存）分配 50 MB，并且，如果他们经常打开大文件，则应分配更多的空间。没有为 Internet 临时文件分配空间的最终用户会给 Web 服务器带来非常重的负担。

• 使用大于 25 MB 的文档的最终用户应将文档保存到其本地计算机。如果直接从文档库中打开大文档，将会在文档打开时消耗带宽和资源，并可能会自动将更改直接保存到文档库中的文档。

  最终用户应在打开文档之前右键单击该文档并将其保存到自己的计算机，然后在完成编辑后将任何更改上载到文档库。

• 最终用户不应使用资源管理器视图来查看大文档，而是应使用“所有文档”视图。在资源管理器视图中打开 SharePoint 文档库时，如果将指针放在任何枚举的文件上，将会请求所浏览的文件夹中所有文件的元数据。某些情况下，此操作可能会请求整个文件。如果在资源管理器视图中同时浏览多个大文件，这样将会给服务器带来非常重的负担。

• 在文档库中，最终用户不应使用“编辑”菜单上“发送到”子菜单上的“下载副本” 项。“下载副本”选项将在 Web 服务器的内存中打开整个文件。

培训最终用户如何使用大文档库

最终用户使用大文档库的方式可能会对性能产生重大影响。

• 最终用户应使用已经过索引编制可处理大文档库的自定义视图筛选器，而不应直接访问这些库。

• 鼓励最终用户不要使用资源管理器视图来查看大文档库，而是应使用“所有文档”视图。在资源管理器视图中打开 SharePoint 文档库时，如果将指针放在任何枚举的文件上，将会请求所浏览的文件夹中所有文件的元数据。某些情况下，此操作可能会请求整个文件。在包含很多项的文件夹中，此过程可能会花费很长时间，并且可能会影响服务器场的性能。

• 与最终用户合作，以针对其需求创建适当的视图，并防止他们为大型列表创建其自己的视图。如果有包含多个大型列表的 Web 应用程序，则可能要考虑为整个 Web 应用程序禁用“管理个人视图”权限。

管理大型列表以提高性能

SharePoint 产品和技术支持大型列表。但是，您必须小心控制最终用户查看列表的方式，以帮助防止对性能产生负面影响。

• 为了获得最佳性能，列表级别（例如，列表的根或单一文件夹）中的项数不要超过 2,000 项。

• 如果必须创建和浏览大型列表，请使用以下最佳做法：

  • 对列表中的一个或多个列进行索引。

  • 将列表的默认视图更改为采用以下建议的自定义筛选视图：

    • 视图返回的项数少于 5,000 项。

    • 用于筛选视图的第一列具有索引，并且足以减少返回的总项数。

    • 视图只显示绝对需要的那些列。

    • 视图包括尽可能少的查找列。视图所包括的列表中的每个查找列都会导致额外联接到数据库以及额外调用数据库。

• 评估列表大小时考虑列表中的列数。包含大量列的列表执行速度可能较慢。

请注意，以下设置和操作可能会对具有大型列表的网站的性能产生重大影响。

• 复杂的显式权限（列表或库、文件夹或者项或文档级别上的权限）会强制对每一项进行授权检查。

• 更改授权设置。

• 创建、更新和删除索引。

• 导入和导出内容。

• 删除列表。

• 部署新的内容类型或更新现有内容类型。

如果有生成大量任务和历史记录项的工作流，则可能会创建大型列表。对于活动程度非常高的工作流，请采用以下做法：

• 保持 AutoCleanupDays 计时器作业运行，以便清理 60 天以前的已完成工作流上的任务。

• 在创建工作流关联时，如果预计某个工作流将频繁使用，或者将创建大量的任务和历史记录项，请使用非默认任务和历史记录列表。

请注意，如果有使用大型列表的网站，该网站可能会降低利用 Stsadm 备份操作执行的网站集备份的性能。

如果您计划使用或当前拥有非常大的列表，强烈建议您阅读以下资源：

• 管理包含多项的列表和库 (https://go.microsoft.com/fwlink/?linkid=105579&clcid=0x804)

• 白皮书：使用 Office SharePoint Server 2007 中的大型列表 (https://go.microsoft.com/fwlink/?linkid=105580&clcid=0x804)

下载此书籍

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

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

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