Improve performance of a Compound Employee API query having multiple 'QueryMore' operation calls.
There is a feature called 'Server Paging' which helps in improving the overall performance of the Compound Employee Query having multiple 'QueryMore' operation calls.
Below is a brief on what the feature is and how it works-
Server paging optimizes the paging of Query and QueryMore calls. After activating this feature, the determination of the person ids will be executed only once without using standard paging. The API will retrieve the complete list of person ids to be extracted in one single database query and store this list in the query session. The query and all subsequent queryMore calls will retrieve the next page of person ids from the stored list instead of executing an additional database query. This reduces the number of queries and the execution time of the API, especially if complex conditions like the last modified condition are used in the SFQL request.
Server paging can be activated in provisioning in the SFAPI feature settings.
Because of security reasons there is a limit of the number of person ids which can be stored in the query session and the corresponding http session. If the limit is reached and a new query is executed, it will not be allowed to use server paging and standard paging will be applied. The current limit is 1,000,000 ids per http session.
So if you face performance issues even after enabling this feature, you may need to check if the number of records returned by the query is going to exceed this limit.
NOTE: Compound Employee API server paging works in a similar way to OData API snapshot-based server pagination. See the Help Portal link below for more information on Compound Employee API server paging.
How to improve performance of CompoundEmployee API query having multiple 'QueryMore' operation calls, Server Paging feature of Compound Employee API, server-side, snapshot, pagination , KBA , LOD-SF-INT-API , API & Adhoc API Framework , LOD-SF-INT , Integrations , How To