在迭代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仍然使用内部分页。所以我的问题是:在这种情况下选择什么页面大小?一方面,页面大小越多,到服务器的往返次数就越少。另一方面,我们不能过多地扩大它,因为每个周期性请求可能变得太大和缓慢并且也可能导致性能降低。中庸之道在哪里?
答案 0 :(得分:3)
这里没有中庸之道,因为它是三个因素之间的权衡:CE返回结果的速度,进行的往返次数以及客户端和服务器上的内存消耗。您可能理解,这些很大程度上取决于您的操作环境。
您可以将影响查询性能的默认配置参数视为合理的并且是一种基线:
ServerCacheCofiguration.QueryPageMaxSize
:1000
ServerCacheCofiguration.QueryPageDefaultSize
:500
ServerCacheCofiguration.NonPagedQueryMaxSize
:5000
一种好的方法是使用相应数量的对象填充测试对象库并使用查询参数进行播放。