サーバ側のタイムリミットの設定と、リコメンデーションのバックアップの設定はLiftIgniterのバックエンド設定から管理します。これらの設定を行う場合は、LiftIgniterにご連絡ください。ここにいくつかの設定の例を説明します。
最大の透明性を維持するため、デフォルトでサーバ側のリコメンデーションのバックアップを有効にしていません。Javascriptの組み込みを行っているお客様には、クライアント側でクエリの再送信とリコメンデーションのバックアップが行われるため、これによる影響はほとんどありません。サーバ側での組み込みを行っているお客様には、一般的にデフォルトではエラーや通信の失敗への対応は、お客様側で行っていただきます。しかしながら、どのお客様でも、サーバ側でのリコメンデーションのバックアップを有効にすることができます。
サーバ側のタイムリミット（デフォルトでは1,300ミリ秒、短縮することができます）
LiftIgniterのシステムは、限られた時間の中で最高のレスポンスを処理するように設計されています。多くのケースでは、処理に要する時間は特に制限がない状況では200ミリ秒以下です。しかしながら、まれに膨大な量のデータを持つクエリや、一時的なサーバの読み込みの問題によって、クエリの送信に多少時間がかかる場合があります。
現在、サーバ側のタイムリミットは、クエリの処理に関連するすべての処理を含めて、1,300ミリ秒に設定しています。このタイムリミットは、最悪のケースでの遅延時間の保証と、タイムアウトの制限のバランスを考慮した上で設定されています。（より低いタイムリミットを設定することで、最悪のケースでの遅延時間を短縮することができますが、タイムアウトの制限が若干高くなります）
しかしながら、お客様によってはもっと速いレスポンスを必要とする場合があります。例えば、お客様が200ミリ秒以内のレスポンスを必要としているのに、それ以上の時間を要するレスポンスが意味を成さない場合は、より低いタイムリミットを設定することができます。このタイムリミットは、サーバ内での処理に要する時間で、ラウンドトリップタイムは含んでいません。お客様が許容できる最大の遅延時間と、サーバ間のPingの遅延時間を考慮して正しいタイムリミットを設定します。
タイムリミットを低く設定することで、タイムアウトの制限を上げる可能性があるだけでなく、タイムリミットに合わせた処理時間を実現するために、処理プロセスを短縮させるようなケースでは、クエリのレスポンスの質が最適ではなくなる可能性があります。
サーバ側でのリコメンデーションのバックアップ
サーバ側でのリコメンデーションのバックアップを返す設定を有効にすることができます。
これらは、タイムリミットを経過しても処理が終わっていない場合や、サーバがオーバーロードの状態にあり、リソースを維持する必要がある場合などの最終手段としてサーバが返す、デフォルトのリコメンデーションです。これはエラーを返す以外の手段がないようなケースで発生します。
我々のサーバは、限られた時間内でどれだけの処理を行うか調整して、時間制限が近づくと部分的な処理結果を返すため、このようなリコメンデーションを返すことが必要になるケースはほとんどありません。
サーバ側でのリコメンデーションのバックアップを行う利点としては、APIを使用している場合では、エラーが発生する確率を下げることです。
ここでは2つの制限事項があります:
- このようなリコメンデーションのリクエストを送る場合、返されるリコメンデーションはコンテキストに沿ったものではなく、ルールや制約にも則っていない場合があります。
- この場合では、まだネットワーク接続に関する問題を含む、他のエラーの問題を特定していません。
通常ではこの制限事項が利点を大きく上回るため、デフォルトではリコメンデーションのバックアップを有効にしていません。しかしながら、クエリが特別なルールやフィルタを含んでいない場合で、リコメンデーションのバックアップのほうが質が高いと考えられる場合は、この方法を選択することが理にかなっていると考えられます。もし、レスポンスにおける失敗や時間がかかるといった問題がネットワーク接続側の問題である場合は、お客様側でエラーの対応をする必要があります。
サーバ側でのリコメンデーションのバックアップが有効になると、空のクエリを送って、それぞれのサーバで20分ごとにリコメンデーションを更新します（サーバごとに異なるリコメンデーションのバックアップを持ちます）。サーバの更新に失敗すると、以前ストアされたリコメンデーションのバックアップを保持します。