Optimize paged searches using caching

When the server processes an indexed search using the simple paged results control, it builds the entire candidate set of entry IDs for entries that match the search before serving a subset of entries on a results page. By default, the server does this for every page. The larger the candidate set, the longer the search processing takes.

To improve paged search speed, you can configure the server to cache the generated candidate set using the simple-paged-results-id-set-cache-duration property. For example:

$ bin/dsconfig set-backend-prop \
  --backend-name userRoot \
  --set "simple-paged-results-id-set-cache-duration:1 m"

With this property configured, although the server still has to build the entire candidate set before serving the first page of results, it can cache and reuse that set when returning subsequent pages.

By default, the cache duration is set to 0 milliseconds, and no caching is performed. If you change the value to a non-zero duration, the server caches and reuses the candidate set for the subsequent pages of results, up to the point where the duration between requests for the next page of results exceeds the cache duration.

You should configure a duration that is long enough to ensure that the cached result set doesn’t expire before legitimate clients can make use of it, although making the duration too long can cause the server to hold onto the cached result sets longer than necessary, increasing the amount of memory required to hold them.

In most cases, we recommend setting a duration of 30–60 seconds.

When the cache is enabled, it’s not shared between server instances. If possible, clients should send requests for all pages of a paged search to the same server, whether caching is enabled or not. The PingDirectoryProxy server automatically tries to route requests to the same backend server for paged searches, but environments that use other forms of load balancing might not conform to this best practice by default. PingDirectory can properly handle cases where client requests for different pages are sent to different servers, although each server instance involved builds the paged search request candidate set independently.

When optimizing paged searches, you should make the previous configuration change for each local database backend where you expect searches with paged results and enable it for all servers in the topology that might process searches using the paged results request control.

Only enable simple paged results ID caching in environments where all servers support this feature. In a mixed-version topology that includes older versions of the PingDirectory server that don’t support paged results caching, those servers won’t be able to decode paged results cookies generated by newer servers that do support caching. If you disable paged results caching on the newer servers, the cookies these servers generate will be compatible with the older servers.