Server-side timeout settings and backup configurations are controlled through backend configurations of LiftIgniter, so in order to have these set up, you will need to contact Support. Here are the various options we can set up for you:
For maximum transparency, we do not enable server-side backup recommendations by default. For our customers using our JavaScript integration, this should not matter much, because we have Query retries and backup recommendations on the client side. For customers using our server-side integration, the general default is for them to handle failure and error cases themselves. However, we can enable server-side backup recommendations for any customer.
Server-side time limit (default 1300 ms, can be shortened)
LiftIgniter's computational engine tries to compute the best response within the time available to it. In the vast majority of cases, the computation takes under 200 ms without any time restrictions. However, occasionally, due to a huge amount of data to consider for the query context, or temporary server load issues, the query can take a little longer.
We currently set a server-side time limit of 1300 ms on the query as a whole, with corresponding time limits on various stages of the query processing. This time limit is chosen as a default rule to balance a guarantee of low worst-case latency and low timeout rate (if we chose a lower time limit, we'd have better worst-case latency, but slightly higher timeout rate).
However, for some customers of ours, fast responses are essential. For instance, a customer might want a response from us within 200 ms, so a response that takes longer than that is useless. In such cases, we can configure lower time limits. Keep in mind that this time limit includes only time spent within the server and does not include round trip time. Based on the maximum latency you can tolerate and the ping latency between the servers, we will decide the right time limit to place.
Also keep in mind that setting a lower time limit will not only potentially increase the timeout rate, it could also cause slightly suboptimal query responses in cases where we have to cut short computation to return a timely response.
Server-side backup recommendations
We can enable the option to return server-side backup recommendations.
These are "last resort" default recommendations that the server returns if the time limit is hit and the computation is not yet over, or if the server is overloaded and needs to conserve computational resources. They will be used only in cases where we would otherwise have had to return error messages.
The need to return these should be rare, because our server tries to adjust how much computation it does to the time available, and tries to return a partial result when close to the time limit.
The main advantage of server-side backup recommendations is that they reduce the error rate for you if you're using our API.
There are two limitations:
- The recommendations are not necessarily contextual. Within server-side recommendations, we first try to return backup recommendations specific to the current item the user is on, if applicable. Otherwise, we return a global backup. In either case, the recommendations may not respect all the rules and filters of the query (it will still respect any global filters that do not depend on query parameters).
- They still don't address other sources of error, including network connectivity.
Since the limitations generally overwhelm the advantages, we don't enable backup recommendations by default. However, they may make sense for you if your queries don't include special rules or filters, and you expect our backup recommendations to be better than yours. Note that to address network connectivity, you would still need some error handling on your side for a response that fails or takes too long.
Global server-side backup recommendations are refreshed every 20 minutes; the item-based ones are filled in as people access individual items.
In order to know whether a given recommendation response is using backup recommendations, you need to include "getQueryInfo" : "true" in the query parameters, and then look for the value of queryInfo.backupType in the response. There are three possibilities:
- "N/A" means that the query was computed in real time and no backup recommendations were used.
- "item" means that the backup recommendations used the current item, so were somewhat contextual.
- "global" means that the global backup recommendations were used.