了解高项目计数和受限制视图数的性能影响

上一次修改主题： 2009-01-14

本主题将帮助您了解、诊断和解决以下问题：当使用以联机模式运行的 Microsoft Office Outlook、缓存模式下的 Outlook（使用委派访问）和 Outlook Web Access 时，与关键路径文件夹中的高项目计数以及受限制视图请求数相关的 Microsoft Exchange Server 2007 性能问题。关键路径文件夹是“日历”、“联系人”、“收件箱”和“已发送邮件”文件夹。受限制视图是基于搜索条件来限制信息的数据视图，因此这些视图只是文件夹中部分项目的视图。与这些情况相关的性能问题通常都是相关联的，并且在客户端访问速度较慢的情况下，最终用户会明显感受到这些问题。这样只会使在关键路径文件夹中项目计数大得异常的用户引发在您的整个 Exchange 组织中都可以感觉到的性能问题。

对于 Exchange Server 2003，建议每个文件夹的最大项目计数为 5,000 个。在 Exchange 2007 中，由于 I/O、页面大小以及缓存增加，从而有助于增加最大项目计数的建议值。对于采用正确方法配备的硬件，可接受的用户体验仍可高达 20,000 个项目计数。

注意：
对于常见的操作，可接受的用户体验是指从单击到操作的响应时间为 100 毫秒。对于很少使用的操作，例如，创建一个新的排序顺序或第一次选择文件夹时，响应时间长达一分钟也可以接受。

建议的最大值根据任何第三方程序是否访问用户邮箱而有所变化。这些第三方程序包括以下程序以及其他类似程序：

• Outlook 加载项

• 电子邮件存档

• 防病毒

• 移动设备

• 语音邮件

• 其他程序或 Outlook 创建其他视图或搜索文件夹的加载项

在这种情况下，必须通过检查服务器的总负载以及服务器如何处理特定第三方程序中的每个请求来确定项目计数。

此外，建议的最大值还取决于 Exchange 环境的性能容量。特定硬件选项可能会导致最大数减小。理想情况下，最好使“收件箱”和“已发送邮件”文件夹中的项目少于 20,000 个，“联系人”和“日历”的项目计数少于 5,000 个。即使使项目计数小于或等于建议的最大值，但某些操作仍需占用大量时间（通常大约接近一分钟）。这些操作包括新的排序顺序以及首次选择文件夹。甚至首次查看文件夹时也需更多时间才可生成视图。关键路径文件夹中的项目计数很高对服务器性能具有负面影响，因为它们是用户邮箱中最常被访问的文件夹。其他文件夹（特别是由最终用户创建的自定义文件夹）可以处理更多的项目，而不会对用户体验有负面影响，因为对它们的访问较少。请注意，尽管在不常访问的文件夹中具有的项目计数较高所带来的性能影响已降低，但这些文件夹中的高项目计数仍然会带来断断续续的性能问题，因为类似文件夹的数量在上升，并且服务器上的活动用户数也在增加。

要点：
甚至首次查看文件夹时也需更多时间才可生成视图。因此，移动邮箱操作将导致具有高项目计数的所有文件夹的第一个视图性能下降。这会导致已移到新服务器的用户访问其文件夹和重新创建文件夹视图时将出现断断续续的性能问题。按照最佳实践操作，即：将移动操作分布到多个服务器并减少同时移到同一服务器的邮箱数量，有助于最大程度地减少此问题。

当您为组织考虑正确的最大项目计数时，请务必记住：最大值中不存在崖，但性能会不断降低。所述限制不是硬编码限制。这些数字根据测试和代码分析而定。当项目计数增加时，用户可能会明显感觉到性能下降。您环境中用户可接受的性能级别即表示该环境适用的相应最大项目计数。

了解各个邮箱没有固有的大小限制。限制邮箱大小的主要因素如下：可用磁盘空间、备份和还原时间、服务级别协议和 Outlook 性能。当提到 Outlook 性能时，我们特别指的是最终用户体验到的延迟。

了解硬件选择的性能影响

尽管以下内容是不言而喻的，还是需要重复一下：如果您组织的硬件大小不合适，则在项目数量较少的情况下性能依然糟糕。在联机模式下，系统的 I/O 要求将随着邮箱中项目计数的增加而增加。当您围绕高项目计数评估硬件性能时，磁盘延迟是一个最需要考虑的硬件事项。为了获得最佳用户体验，请确保磁盘延迟很小（20 毫秒或更少），即使在服务器使用率最高时也是如此。

若要显示磁盘延迟如何可以提高及影响服务器性能，请考虑以下示例。在请求某个视图时，对数据的请求单独执行，对于来自磁盘的序列化请求不进行批量操作。例如，如果某个插件返回了一个具有 1000 封邮件的视图，则 Exchange 存储将很可能对数据做出 200 次左右的单独请求（假设每次请求大约检索 5 封邮件）。在磁盘延迟为 20 毫秒的情况下，磁盘子系统单独就造成了 4 秒的延迟。请考虑到，随着磁盘延迟增加到 50 毫秒或 100 毫秒，性能影响也会增加。如果使用多个插件进行类似的请求，问题会变得更加复杂。在这种情况下，用户可能会发现 Outlook 被频繁阻止。

有关建议调整服务器大小以确保 Exchange 2007 具有良好性能的详细信息，请参阅规划服务器体系结构和存储体系结构。

了解为什么可能需要额外处理时间

在您考虑高项目计数和受限制视图请求数对服务器处理能力的性能影响时，应该注意执行的基本处理操作，以及高项目计数和受限制视图请求如何与这些处理操作相关。

文件夹内容存储在信息存储数据库的表中。随着项目数量的增加，存储复杂性也会相应地增加。Exchange 存储的存储机制是可扩展存储引擎 (ESE)。ESE 使用 B+ 树数据结构来存储记录。随着记录数量的增加，需要用于查找信息并遍历 B+ 树的磁盘 I/O 请求的潜在数量也在增加。有关详细信息，请参阅可扩展存储引擎体系结构。

随着项目数量的增加，任何请求的数据位于硬盘上的物理相邻位置的可能性大大减小。因此需要更多的 I/O 请求。

创建受限制视图时，需要从 Exchange 服务器中进行处理。

有两种方法可以筛选 MAPI 中的邮件：

• 搜索文件夹

• 限制

  限制是通过调用 MAPI 表中的 IMAPITable::Restrict 方法创建的。结果表仅显示匹配指定限制的项目。限制内容表仅显示一个文件夹中的邮件。此类限制有时可能会与描述搜索文件夹筛选条件的 MAPI 定义结构相混淆。此类 MAPI 定义结构也称为限制。

搜索文件夹和限制需要进行额外处理。例如，创建搜索文件夹，并使用与用户标准匹配的项目填充搜索文件夹。此过程需要检查文件夹中的每个项目以确定是否应该将每一项都放在搜索文件夹中。因此，如果文件夹中包含很多项目，则需要更多的时间来创建视图。这些搜索文件夹会作为 SearchFID 存储在发起搜索的每个文件夹下。默认情况下，在填充了搜索文件夹后，此文件夹最多可以存在 40 天。

受限制视图的存在会影响对文件夹中的项目做出修改的速度。如果搜索文件夹与某个文件夹相关联，则在其他文件夹中添加、删除或更新项目时必须发生更多处理操作。由于 Exchange 必须确定搜索文件夹是否必须进行更新，因此会出现这种情况。如果您建立了很多搜索文件夹，则对所有搜索文件夹进行的每个更改都必须进行评估，以确定是否必须更新搜索文件夹。

如果将更多的非标准属性添加到 Outlook 中的文件夹视图中，则可能需要额外的远程过程调用 (RPC) 检索来自 Exchange 存储的非标准属性。如果某个文件夹包含很多项目，则需要更多的往返来检索来自 Exchange Server 的数据。

在您尝试查看日历文件夹时，Outlook 必须找到指定日期范围中的所有约会。这需要至少两个处理请求。第一个请求获取指定日期范围中的所有静态约会。第二个请求查找发生在指定日期范围内的所有定期约会。处理第二个请求所需的时间与日历文件夹中的项目数量成比例。由于 Outlook 请求所有定期约会，因此会出现这种情况。在收到定期约会列表后，必须检查每个定期约会以确定约会是否在指定的日期范围内发生。如果日历包含很多项目，则需要更多的时间来处理这些请求。

了解项目计数与邮箱大小的性能影响

了解大多数的性能问题不是大型邮箱（定义为大于或等于 2GB 的邮箱）所造成的结果，而是由服务器上正在被访问的一个或多个文件夹中的项目数量所造成的。文件夹中有很多项目会对性能造成负面影响，因为这些文件夹中的操作将花费更长的时间。特别是，关键路径文件夹中项目的数量会极大地影响性能。“日历”、“联系人”、“收件箱”和“已发送邮件”文件夹。有关如何计划大型邮箱的详细信息，请参阅 White Paper:Planning for Large Mailboxes with Exchange 2007（英文网页）。

取决于文件夹中项目数量的操作包括将新列添加到视图中、对新列进行排序、查找和搜索。很多 Outlook 插件在其运行时都会执行排序或搜索操作，并且这些请求可能与其他 Outlook MAPI 请求重叠。这会导致用户体验非常糟糕。

如果在缓存模式下运行（Outlook 2003 及较新版本的默认模式），则随着文件夹中项目数量的增加，客户端性能会成为一个问题。您应该执行的操作是使您的 OST 文件（本地数据缓存）不会成为片断。可以使用 Windows SysInternals 工具 Contig 来达到此目的。要下载最新版本的 Contig，请参阅 Contig v1.55（英文网页）。

除了关键路径文件夹中项目的数量，还有其他因素会影响 Outlook 体验，项目计数（如其他 MAPI 应用程序的数量或在用户计算机上运行的 Outlook 插件数）很高也会使 Outlook 体验变得糟糕。所有 MAPI 请求都需要使用 emsmdb32.dll 处理时间。如果用户具有的许多插件都提出请求，则 Outlook 将运行得更慢，并且对服务器的影响可能加大。此外，所请求操作的复杂性也将有影响。例如，将文件夹内的所有项目标记为“已阅读”比标记一个项目花费的时间长很多。可能占用很长时间的其他操作包括在进行会议请求时检索许多用户的闲/忙信息，或在多个文件夹中执行搜索。如果用户频繁地执行复杂操作，具有许多 Outlook 插件，或者经常使用“联系人”和“日历”文件夹，则用户由于项目计数很高而感觉到性能下降的可能性大大增加。

了解受限制视图（MAPI 限制）

MAPI 表示通常以表的形式存在的数据。当客户端请求提供程序列表、文件夹表、文件夹内容表、附件表及更多表时，会向其提供一张表。每张表都由列组成。每一列都是一个不同的 MAPI 属性，表示如“发件人”、“主题”和“传递时间”等属性。每一行都表示一个特定的项目。对于文件夹内容表，每一行表示邮件。对这些表所采取的客户端操作由类似于对数据进行排序的活动表示。客户端可以在表中查找到与指定条件相匹配的特定行。此操作称为 FindRow()。还可以请求只将满足特定条件的项目包含在表中。一个示例是仅包括在特定日期创建的项目。这就是所谓的限制。生成的文件夹内容表将只具有表中满足给定条件的项目。在预计客户端将频繁请求相同的数据表示时使用限制。

受限制视图如何影响性能

若要了解限制对性能造成的后果，必须考虑到“信息存储”实际上存储了 MAPI 客户端所请求的数据，以及解释请求（如 FindRow 和 Restrict）的方式。在此存储的存储架构内，具有各种表，共同表示如邮箱、文件夹、文件夹内容和邮件等内容。

如果客户端请求文件夹内容的列表，则该请求会映射到称为 MessageFolder Table (MsgFolder) 的特殊文件夹。系统中创建的每个文件夹都具有一个单独的邮件文件夹表。MsgFolder 表的作用是将文件夹映射到其内容。

若要处理限制呼叫（对相同数据的频繁重新请求）的期望结果，将创建一个新的特殊文件夹（以及相应的 MsgFolder 表），称为“限制搜索文件夹”。此文件夹将链接回原始文件夹，并且这两个文件夹之间会存在逻辑关系。条件将置于搜索文件夹中，这样它应该仅包括满足由限制所指定的条件的项目。在此搜索文件夹中，MsgFolder 表中满足限制条件的每封邮件都存在 MsgFolder 表中原始行的反向链接。

此行为所遇到的性能问题是管理对每个搜索文件夹的更新所需要的时间。当原始文件夹上发生更改时，此更改会与所讨论文件夹相关联的每个限制搜索文件夹进行比较，以确定是否必须也对这些文件夹进行更新。如果一个或多个文件夹中存在大量搜索文件夹，则会产生更大的影响。遇到的第二个问题是创建限制搜索文件夹。创建限制搜索文件夹需要完全传递原始文件夹，以提取必须链接到限制搜索文件夹的各个项目。如果此过程作为客户端操作的直接结果发生，则时间延迟可能会导致用户体验到挂起，或接收到 Outlook RPC 弹出框，表明请求需要花费很长时间来处理。用于创建限制搜索文件夹的时间与常规文件夹中的项目数量成比例。随着文件夹中项目数量的增加，这些项目将位于相邻磁盘扇区的可能性大大降低。在满足对项目计数很高的文件夹的限制视图请求时，这会导致随机磁盘 I/O 显著增加。随着对项目计数很高的文件夹的限制视图请求数量增加，访问服务器上资源的所有用户都将感觉到 IO 增加所带来的影响。

在 Exchange 2000 Server、Exchange Server 2003 和 Exchange Server 2007 中，每个文件夹上允许的限制搜索文件夹都达到了最大数量。默认的最大数量是 11，并且搜索文件夹的默认生存期为 40 天。

基于先入先出 (FIFO) 原则处理限制搜索文件夹。如果某个文件夹已经具有 11 个与之相关的限制搜索文件夹，并且做出了新的限制请求，则通过最后一次实际使用的限制来评估搜索文件夹列表。这表示将删除使用最少的限制搜索文件夹以允许处理新的请求。如前面提到的，这需要完全传递常规 MsgFolder 表，如果此操作已由客户端作为直接操作完成，则在构建该表并将该表提供给客户端时，客户端可能会感受到性能问题。因此，以每日或每周为基础，可能会需要 12 个以上的限制搜索文件夹。这会导致客户端收到一个当前不具有匹配搜索文件夹的限制请求。进而导致删除限制搜索文件夹并创建新的文件夹。所有这些请求都会连续进行处理。这表示如果有很多用户在被定期请求限制视图的文件夹中具有非常高的项目计数，则这些请求可能要排队。这将导致访问驻留在服务器上的邮箱数据的所有用户感觉到总体速度很慢。了解这不仅仅是影响正在访问其邮箱的用户。例如，访问存储在服务器上的日历数据的其他服务器上的用户也将感觉到速度很慢。

要点：
在联机模式中在客户端安装额外的区域设置可以为用户创建更多的 Outlook Web Access 和 Outlook 视图。

限制视图和共享日历

如果您要查看其他人的“日历”、“联系人”等文件夹，则在查看这些文件夹之前可能会有一些延迟。在查看文件夹之后，来回切换的速度会相当快。但一段时间之后，访问文件夹的速度又将变慢。如果日历中项目的数量超过 5000，则延迟时间将特别长。

当 Outlook 访问其他人的文件夹时，将应用可限制用户查看私人项目的视图。

对文件夹应用视图的操作会在存储中创建搜索文件夹。创建搜索文件夹时，会对其进行缓存以供将来使用。如果用户尝试创建已存在的搜索文件夹，则会使用缓存的搜索文件夹。这会使得将来的查看速度变得非常快。

默认情况下，Exchange 不会无限期地缓存所有搜索文件夹。缓存太多的搜索文件夹可能会在更新搜索文件夹时导致服务器端延迟。反之，如果没有缓存足够多的搜索文件夹，将产生类似的问题，因为必须生成和更新搜索文件夹。

若要说明此问题，请考虑将 Exchange Server 配置为在每个文件夹中保留 11 个搜索文件夹（视图）的方案。假设 Frank 有一个与其他 15 个用户共享的“日历”文件夹。Sally 访问此文件夹，并在其搜索文件夹的构建过程中感到延迟。在构建文件夹之后，访问速度变得非常快。然后 Sally 一天没有查看此文件夹，而其他的 11 个用户访问了此文件夹。将为他们每个人构建一个新的搜索文件夹。由于只缓存了 11 个搜索文件夹，因此当第十二个用户访问此文件夹时，Exchange 将删除为 Sally 构建的搜索文件夹。现在，当 Sally 下一次访问此文件夹时，她必须等待 Exchange 构建她的搜索文件夹。

假设我们将 Frank 的邮箱服务器配置为缓存 20 个视图。然后，Sally 和其他 14 个用户都可以访问 Frank 的日历文件夹，并且将只创建 15 个搜索文件夹。由于 15 小于 20，我们绝不会多循环出一个视图，因此在最初访问时创建了搜索文件夹之后，访问速度对每个人来说都变得非常快速。

缓存搜索文件夹的默认数量是 11。此配置是在数据库级别设置的。可以使用 ADSIEdit 来查看已配置的值。使用 ADSIEdit 查看存储对象，然后检查 msExchMaxCachedViews 属性。可分辨名称如下：

CN=Database, CN=Storage Group,CN=InformationStore,CN=Server NAME,CN=Servers,CN=AG Name,CN=Administrative Groups,CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com。

在某些情况下，将该值修改为大于 11 的值对于调整对环境的性能影响非常有用。

要点：
不应将 msExchMaxCachedViews 属性值设置为大于 50。

要点：
如果在环境中具有 Outlook 2003 RTM，请确保在使用共享日历时部署 Service Pack 1 或较新版本以解决关于性能低下的已知问题。