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?
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.