サービスカタログ |トラブルシューティング - 非常に大きなテーブルを指すルックアップ選択ボックス変数が原因で、カタログアイテムのロード時にパフォーマンスの問題が発生するIssue [選択ボックスをルックアップ] 変数は、[テーブルからルックアップ] および [値フィールドをルックアップ] フィールドで指定された任意のテーブルから利用可能な選択肢をプルします。 [選択ボックスをルックアップ] タイプの変数を含むカタログアイテム、注文ガイド、または変数が表示される場所で、次の現象が発生する可能性があります。 カタログアイテムのロードに時間がかかる (サービスポータルで同じ)サービスポータルの注文ガイドのロードに時間がかかる注文ガイドのカタログアイテムのロードに時間がかかる ReleaseすべてのリリースCauseルックアップ選択ボックスタイプ変数が大きなテーブルで構成されている場合、システムはこのテーブルから利用可能なすべての値をプルし、カタログアイテム注文ページに表示します。表示できる選択肢の最大数は 10,000 ですが、その制限は極端なパフォーマンスの低下を防ぐだけです。たとえば、インスタンスのメモリーが不足しないようにするなどです。この制限により、変数によってフォームのロードが遅くなるのを防ぐことはできません。選択ボックスの参照修飾子に一致するレコードの数に応じて、応答時間は直線的にスケーリングされます。たとえば、あるケースでは、ルックアップ選択ボックスが 100 万件のレコードを持つ CMDB テーブルを指しているため、フォームのロードに平均 2 分以上かかりました。 ほとんどの場合、利用可能な値は選択肢 [sys_choice] テーブルから取得できます。ベストプラクティスは、可能な限り選択肢テーブルを使用することです。それ以外の場合は、参照修飾子を使用して返される値の数を制御します。 たとえば、インシデントテーブルには、メール、電話、Web などの選択肢がある優先連絡先タイプフィールドがあります。ルックアップ選択ボックス変数が、インシデントテーブルが [テーブルからルックアップ] フィールド、優先連絡先タイプが [ルックアップ値フィールド] フィールドであるカタログアイテムで使用されました。これにより、インシデントテーブル全体 (場合によっては数百万件のレコード) が評価され、利用可能なオプションがいくつか決定され、提供されます。インシデントテーブルが大きくなると、ユーザーのパフォーマンスがますます低下します。この場合、[インシデント] テーブルの [優先連絡先タイプ] フィールドのオプションが格納されている [選択肢] テーブルを参照することをお勧めします。評価する必要があるオプションは 3 つだけで、カタログアイテムフォームのロード速度が大幅に向上します。Resolutionパフォーマンスの問題は、取得して画面に表示する必要がある結果の数に比例します。参照修飾子を使用して結果の数を制御し、取得されるデータを減らします。 確認すべき質問: 取得されたすべてのデータが必要ですか?そうでない場合、必要なデータ (データのサブセット) のみを取得するために使用できる参照修飾子はどれか? 値は選択肢 [sys_choice] テーブルから利用できますか?一致する場合は、大きなテーブルからフィールドを直接クエリするのではなく、選択肢テーブルを使用します。[選択肢] テーブルから取得されるデータが大幅に小さくなります。 [選択ボックスをルックアップ] タイプの代わりに [選択ボックス] タイプを使用したり、複数選択肢タイプを使用したりできますか? これらの代替手段はいずれも、「選択ボックスをルックアップ」変数タイプのパフォーマンス向上に役立ちます。 パフォーマンスに関連するその他のトラブルシューティング記事については、ここをクリックしてください。 [選択ボックスをルックアップ] 変数タイプのドキュメントについては、以下を参照してください。 https://www.servicenow.com/docs/csh?topicname=r_VariableTypes.html&version=latest