与 SharePoint Foundation 同步时出现的性能问题
上次修改时间： 2009年10月8日
适用范围： SharePoint Foundation 2010
本文内容
延迟
吞吐量
带宽
分页
筛选和排序
在与服务器进行同步时，需要记住一些性能问题，其中包括一些会影响项目性能的项目，例如延迟、吞吐量、带宽、分页以及用于返回特定数据集的筛选和排序。
延迟
延迟是指用户发出请求到用户收到从服务器返回的信息之间的时间延迟，它对于用户非常重要。通常既存在对处理数据库或前端 Web 服务器上的请求所允许花费的时间量的限制，又存在对请求本身大小的限制，因此非常长的请求会变成被拒绝的请求。
虽然由于上述原因使得利用 GetListItemChangesSinceToken 上的 rowLimit 属性来限制每次请求的数据量显得至关重要，但应清楚地认识到一点，即，使用此属性也将增加完成同步过程所需的总时间量。
吞吐量
很显然，通过减少处理请求所需的总周期数可以减少时间延迟，从而帮助改进性能。不过，对于多个客户端，减少一个客户端对其他客户端产生的不利影响更加重要。大多数时间内，要求服务器执行一些处理与在多个客户端上实现相同的处理相比，前者要更加轻松、简单、安全和高效。但若要增加吞吐量，在客户端上进行处理所获得的效果总是要好得多。虽然服务器可能具有更强的处理能力，但客户端可能具有更多的可用 CPU 时间。来自同步客户端的对服务器的数据请求应尽可能的小而简单。
带宽
虽然我们以实现高带宽方案为目标，但即便是这样，尝试最小化通过网络发送的数据量也很重要。如果客户端不需要某些信息，则请求不应包含这些信息。
分页
当执行完全同步（无更改令牌）时，客户端应通过使用 rowLimit 参数来请求每页返回的最大项数。如果列表中筛选的项数大于每页返回的最大项数，服务器将返回一个可用于请求下一页的 ListItemCollectionPositionNext 属性。
仅返回第一页上的列表的当前更改令牌，以便对第一页所做的更改不会丢失。客户端将存储第一页中的更改标记以进行后续增量同步。
备注
辅助页不包含列表和全局属性，如权限、备用 URL 和生存时间 (TTL) 值。
使用行限制
虽然增量同步（提供了更改令牌）也支持 rowLimit，但对于增量同步，此元素限制了对内部更改日志进行的处理。另外，存在每个页面的行数为 100 的内部限制。虽然客户端可确保返回的项数绝对不会大于此限制数，但在某些环境中，可能未将所有更改同步，即使返回的项数小于此限制数也是如此。若在更新数等于此限制数时停止处理更改日志，则会出现此情况。如果是这样的话，则应返回 MoreChanges 属性以指明更改日志中发生了更多更改。客户端应使用返回的更改令牌立即请求更多更改，而不是等待下一次同步更新。
rowLimit 会对增量同步产生以下影响：
存在每个页面的行数为 100 的内部限制。没有可用来筛选返回的项目的经修改的时间索引。此外，SQL Server 上查询中的 Or 的数目限制为 160，当数目接近 160 时，查询性能将会开始变得很差。若数目为 100，则意味着我们可将另外的 60 个 Or 作为客户端请求的筛选的一部分。
可以创建多个单独的 SQL 查询，但这将表示支持在中间层上进行的所有排序和筛选。
为此，您必须返回一个并非最新的更改令牌，以便可通过单独调用来处理额外的更改。您仍可以查看整个更改日志，以便更好地确定返回的项数将小于此限制数时的最新时间点，但如果不在中间层进行筛选，此时间点也将不准确。
筛选和排序
在应用筛选时，您可以返回列表中的某个特定项目集，而不是整个列表。两种使用筛选的最常见应用场景包括文件夹同步（其中，用户仅获取文件夹内的项目）；而对于某些主面板应用场景，用户仅获取与该用户关联的项目。
可以使用 contains 参数或 query 参数来进行筛选。由于从根本上说，Contains 是协作应用程序标记语言 (CAML) 查询的 Where 子句，因此它的限制更大，而 query 是完整查询。由于您可以优化某些应用场景，因此使用 Contains 会更加安全。
虽然与 contains 参数相比，The Query 参数不仅功能更加强大，而且使用起来也更加灵活，但您必须了解它会对性能产生什么样的影响。使用以下方法构造查询参数会影响性能：
客户端应使用未建立索引的列，从而避免筛选。否则，获取页面需要对整个列表进行扫描，从而找到请求的项数。
客户端还应避免按照某个列进行筛选，除非为该列建立了索引。否则，获取页面将至少需要对整个经筛选的数据集进行排序。
如果筛选和排序不是针对的同一已建立索引的列，则 SQL Server 可能仍会扫描整个列表以避免对经筛选的数据集进行排序。
增量同步包含一个隐式筛选。也可以请求带有特定标识符 (ID) 的项目。在此情况下，客户端将始终返回仅按 ID 排序的项目。由于数据集中的最大项数限定为 100，因此也可以按其他类别进行筛选。
若要按文件夹进行筛选，则可以使用 Folder 查询选项，但应按照 FileLeafRef 对列表进行排序。另外，应首先按照 FileDirRef 对递归查询进行排序。
也可以使用如下类似代码，按多个文件夹进行筛选。
[添加代码头]
"<Or><BeginsWith><FieldRef Name="FileRef"/><Value Type="Note">Shared Documents/folder1/</Value></BeginsWith><BeginsWith><FieldRef Name="FileRef"/><Value Type="Note">Shared Documents/folder2/</Value></BeginsWith></Or>".
这将同步 folder1 和 folder2 的全部内容。
客户端应将此代码与 contains 参数结合使用，并添加以下查询选项。
"<OptimizeFor>FolderUrls</OptimizeFor> "
这将确保对 SQL Server 查询进行适当地优化，方式是将其作为 FileDirRef 和 FileLeafRef 进行排序，并限制合适的列。