【问题标题】:How to optimize page size for IBM FileNet search如何优化 IBM FileNet 搜索的页面大小
【发布时间】:2013-10-30 10:33:01
【问题描述】:

在构建一些服务器端报表时,在迭代 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 内部仍然使用分页。所以我的问题是:在这种情况下选择什么页面大小?一方面,页面大小越大,到服务器的往返次数就越少。另一方面,我们不能将其放大太多,因为每个周期性请求可能会变得太大和太慢,并且还可能导致性能下降。中庸之道在哪里?

【问题讨论】:

    标签: filenet-p8 filenet filenet-content-engine


    【解决方案1】:

    这里没有中庸之道,因为它是三个因素之间的权衡:CE 返回结果的速度、往返次数以及客户端和服务器上的内存消耗。正如您可能理解的那样,这些在很大程度上取决于您的操作环境。

    您可以将影响查询性能的默认配置参数视为合理的东西,并且是一种基线:

    ServerCacheCofiguration.QueryPageMaxSize: 1000 ServerCacheCofiguration.QueryPageDefaultSize: 500 ServerCacheCofiguration.NonPagedQueryMaxSize:5000

    一个好的方法是使用相应数量的对象填充您的测试对象存储并使用查询参数。

    【讨论】:

    • 所以更好的选择可能是将pageSize参数设置为null。这将有机会根据不同的环境调整不同的页面大小。我做对了吗?
    • 这是有道理的。如果需要,它可以覆盖特定查询的默认值。
    • 嗯,还有一件事要记住:增加页面大小时,您可能会遇到事务超时问题..
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-11-02
    • 2020-12-14
    • 2012-01-28
    • 1970-01-01
    相关资源
    最近更新 更多