2

It's common situation when building some server-side reports to use simple Iterator instead of PageIterator when iterating through FileNet collections because you don't need to send document "portions" to clients.

 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();
                //...
            }

But CE API still uses paging inside. So my question is: what page size to choose in this case? On one hand, the more page size, the less count of round-trips to server. On the other hand, we can't enlarge it too much because each periodical request may become too large and slow and may cause perfomance degradation as well. Where is the golden mean?

sermolaev
  • 975
  • 11
  • 23

1 Answers1

4

There is no golden mean here since it is a trade-off among three factors: how fast CE returns results, how many round-trips are made, and the memory consumption both on the client and the server. As you probably understand, these depend heavily on your operating environment.

You can consider default configuration parameters that affect query performance as something reasonable and being a sort of the baseline:

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

A good approach would be populating your test object store with commensurate number of objects and play with query parameters.

ﾤ ﾡ
  • 5,669
  • 6
  • 43
  • 57
  • So the better choice might be to set pageSize parameter to null. This will enable opportunity to adjust different page sizes depending on different environments. Did I get it right? – sermolaev Oct 31 '13 at 03:24
  • This makes sense. It leaves the possibility to override default value for specific queries if needed. – ﾤ ﾡ Oct 31 '13 at 05:17
  • Well, there is one more thing to keep in mind: when increasing page size, you can end up with transaction timeout issues.. – sermolaev Oct 31 '13 at 09:02