Effect of Parameters on Query Performance

The fastest query is a sequential query that uses the content index. Certain parameter settings will force the query engine to use a less efficient method to resolve the query. To guarantee fast queries, set CiSort to nothing (or descending by rank) set CiForceUseCi to TRUE, and do not reference CiMatchedRecordCount, CiRecordsNextPage, or CiTotalNumberPages in the .htx template.

Sequential versus Nonsequential Execution

A query can be executed sequentially (results fetched as needed) or it can be executed nonsequentially (results cached on the server). A sequential query requires fewer server resources, but also has some limitations. Backwards scrolling (CiBookmarkSkipCount < 0) will re-execute the query and scroll forward to the specified position. Sequential queries cannot refer to the following variables: CiMatchedRecordCount, CiRecordsNextPage, and CiTotalNumberPages.

Either of the following actions will force a query to be nonsequential:

Referring to the CiMatchedRecordCount, CiRecordsNextPage or CiTotalNumberPages variables in the .htx page.
Setting the CiSort parameter to a sort other than the native order of the result. CiSort can safely be set to sort ascending on WorkId (CiSort=WorkId[a]) or descending on Rank (CiSort=Rank[d]).

Enumerated versus Indexed Resolution

Executing queries that must be enumerated can also slow down performance. Most queries are resolved by using the content index, but certain conditions force the query engine to recursively search the disk to locate matching files. These queries include:

Regular expressions on properties other than FileName which begin with a wildcard.
Property value queries when CiForceUseCi is set to FALSE and the index is not up-to-date.
Property value queries involving regular expressions with a wildcard prefix on a property other than FileName (for example, #DocAuthor *son).
Property value queries involving regular expressions that start and end with wildcards (for example, #filename *sample*).
Certain property value queries involving OR (such as @write > -1d OR @create > -1d).

Queries can be forced to use the content index by setting CiForceUseCi to TRUE in the .idq file. The query engine will always use the content index, but query results may be out-of-date for recently modified files. If the content index was used for a query, and some files on disk have been modified more recently than their contents have been filtered, the built-in variable CiOutOfDate will be set to the value 1. In some cases, a query is simply too complex to be resolved solely through use of the content index. In these cases, the built-in variable CiQueryIncomplete will be set to 1. Content queries can always be out of date and can use the content index anytime.

Deferring Nonindexed Trimming

Special support has been put in Index Server to optimize content queries that are sorted descending by rank (CiSort = Rank[d]). For such queries, minimal information can be retrieved from the index, before additional property and security tests are performed. However, if the total number of results matching the query is greater than CiMaxRecordsInResultSet then additional testing must be performed during index retrieval to remove items from this set that fail additional property and security tests. This frees up space in the result set for items matching the full query. This processing uses up resources, and can be deferred by setting CiDeferNonIndexedTrimming to TRUE. The query will then pick CiMaxRecordsInResultSet items first, and trim those. The end result may be a number of matching items less than CiMaxRecordsInResultSet. For queries with the scope set to the entire corpus, on a server with little or no security, you can consider setting CiDeferNonIndexedTrimming to TRUE to improve performance.