在构建一些服务器端报告时,在迭代 FileNet 集合时使用简单的 Iterator 而不是 PageIterator 是很常见的情况,因为您不需要将文档“部分”发送到客户端。
SearchScope ss = new SearchScope(objectStore);
//what integer to choose?
int pageSize;
RepositoryRowSet rrc = ss.fetchRows(sql, pageSize, propertyFilter, true);
Iterator it = rrc.iterator();
while (it.hasNext()) {
RepositoryRow rr = (RepositoryRow) it.next();
//...
}
但是CE API内部仍然使用分页。所以我的问题是:在这种情况下选择什么页面大小?一方面,页面大小越大,到服务器的往返次数就越少。另一方面,我们不能将其放大太多,因为每个定期请求可能会变得太大且缓慢,并且也可能导致性能下降。中庸之道在哪里?
这里没有中庸之道,因为它是三个因素之间的权衡:CE 返回结果的速度、往返次数以及客户端和服务器上的内存消耗。正如您可能了解的那样,这些在很大程度上取决于您的操作环境。
您可以将影响查询性能的默认配置参数视为合理的并且是一种基线:
ServerCacheCofiguration.QueryPageMaxSize
:1000
ServerCacheCofiguration.QueryPageDefaultSize
:500
ServerCacheCofiguration.NonPagedQueryMaxSize
:5000
一个好的方法是用相应数量的对象填充测试对象存储并使用查询参数。