{"_id":"587953668cfb761900c1b063","user":"5668fa9755e4b32100935d41","__v":0,"category":{"_id":"5697430b69393517000c82b5","version":"5668fab608f90021008e8832","__v":3,"pages":["56975a3d59a6692d003fadae","56a2c3dff4f3410d008a84dc","56d88ca37a04df0b00ddf1c7"],"project":"5668fab608f90021008e882f","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-14T06:41:15.588Z","from_sync":false,"order":10,"slug":"faq-troubleshooting","title":"FAQ / Troubleshooting"},"parentDoc":null,"version":{"_id":"5668fab608f90021008e8832","__v":19,"project":"5668fab608f90021008e882f","createdAt":"2015-12-10T04:08:22.769Z","releaseDate":"2015-12-10T04:08:22.769Z","categories":["5668fab708f90021008e8833","569740f124490c3700170a64","569742b58560a60d00e2c25d","569742bd0b09a41900b2446c","569742cd69393517000c82b3","569742f459a6692d003fad8f","569743020b09a41900b2446d","5697430b69393517000c82b5","56a17776470ae00d00c30642","56a2c48a831e2a0d0069b1ad","56b535757bccae0d00e9a1cd","56e1ff6aa49fdc0e005746b5","57e1c88115bf6522002a5e4e","57fa65275ba65a17008b988f","57fbeea34002550e004c032e","58474584889b6c2d00fb86e9","58475dcc64157f0f002f1907","587e7b5158666c2700965d4e","58a349fc30852819007ba083"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.18.0","version":"1.18"},"project":"5668fab608f90021008e882f","updates":[],"next":{"pages":[],"description":""},"createdAt":"2017-01-13T22:23:34.560Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":11,"body":"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](doc:support). Here are the various options we can set up for you:\n\nFor 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](doc:query-retries-and-backup-recommendations-javascript). 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.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Server-side time limit (default 1300 ms, can be shortened)\"\n}\n[/block]\nLiftIgniter'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.\n\nWe 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). \n\nHowever, 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.\n\nAlso 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.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Server-side backup recommendations\"\n}\n[/block]\nWe can enable the option to return server-side backup recommendations. \n\nThese 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.\n\nThe 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. \n\nThe main advantage of server-side backup recommendations is that they reduce the error rate for you if you're using our API.\n\nThere are two limitations:\n\n* The recommendations aren't contextual, and may not implement all the rules and constraints you requested when making the recommendation request.\n* They still don't address other sources of error, including network connectivity.\n\nSince 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.\n\nServer-side backup recommendations, if enabled, are refreshed every 20 minutes on each server by running an empty query (different servers can have different backup recommendations). If the refreshing fails for a server, the previously stored backup recommendations persist.","excerpt":"","slug":"server-side-time-limit-and-backup-recommendations","type":"basic","title":"Server-side time limit and backup recommendations"}

Server-side time limit and backup recommendations


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](doc: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](doc:query-retries-and-backup-recommendations-javascript). 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. [block:api-header] { "type": "basic", "title": "Server-side time limit (default 1300 ms, can be shortened)" } [/block] 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. [block:api-header] { "type": "basic", "title": "Server-side backup recommendations" } [/block] 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 aren't contextual, and may not implement all the rules and constraints you requested when making the recommendation request. * 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. Server-side backup recommendations, if enabled, are refreshed every 20 minutes on each server by running an empty query (different servers can have different backup recommendations). If the refreshing fails for a server, the previously stored backup recommendations persist.