サービスポータルの 6 つの一般的なパフォーマンスの落とし穴とその回避方法Issue この記事の目的は、サービスポータルにおけるパフォーマンスの問題に影響を及ぼすいくつかのシナリオ、問題の診断方法、問題の回避方法について情報を共有することです。 1. Internet Explorer Internet Explorer には、メモリ管理に関連する既知の問題がいくつかあります。これらが原因となって、サービスポータルでパフォーマンスの問題が発生する可能性があります。これらの問題、ならびに回避に関するベストプラクティスの詳細については、「 Internet Explorer 使用時にサービスポータルでのメモリリークを回避するためのベストプラクティス」を参照してください。 2. 自動リフレッシュウィジェット 自動リフレッシュウィジェットにより、パフォーマンスに関する重大な問題が生じる可能性があります。これは通常、/sp/rectangle/ が多数呼び出された結果、セマフォが枯渇するという形で、インスタンス全体で見られます。 このトピックについては次のドキュメントで扱われています。自動リフレッシュするウィジェットが原因でインスタンスの処理速度が低下していますか？ なお、システムパフォーマンスに何らかの影響を与えずにウィジェットを自動更新する方法は実際には存在しません。 3. 大規模なデータセットまたは非効率的なクエリを使用するサーバースクリプト 過剰なデータはパフォーマンスの問題を引き起こす可能性があり、ウィジェットの読み込み速度が低下したり、極端な場合にはインスタンスのメモリ不足に陥ったりすることがあります。これを回避するには、以下の点に留意してください。 過去のすべてのインシデントではなく、現在のインシデントなど、ユーザーが必要とするデータのみにデータを制限します。メモリの過負荷やページの読み込み速度の低下を防ぐため、データ取得を最適化します。 ポータルのパフォーマンス低下を頻繁に引き起こす別の原因は、大量のデータ処理です。通常はウィジェットが使用されているページのロードで遅延が発生します。ただし、極端な場合はインスタンスのメモリ不足が発生します。この問題を回避するため、次の点を考慮してください。ユーザーが本当に確認しなければならないデータはどれほどありますか？例えば、ユーザーが確認したいのは、これまでに自分がオープンしたすべてのインシデントではなく、まだ処理が完了していないインシデントだけかもしれません。 大規模なデータセットは、いくつかの課題を引き起こす可能性があります。 データのクエリ、ACLの評価、ビジネスルールの実行には時間がかかります。データは $scope.data オブジェクトを介してコントローラーに送信されます。このオブジェクトのサイズは、JSON エンコード、HTTP 経由での送信、そしてブラウザでの展開にかかる時間に直接関係します。大規模なデータセットを反復処理して各レコードを処理すると、CPU に大きな負荷がかかるため、ポータルを設計する際にはこの点を考慮してください。 大量のデータ処理を避けるには、以下の点に留意してください。 効果的なフィルターを使用して、ユーザーに本当に必要なデータのみを表示します。データ処理は可能な限り最小限に抑えます。データ使用量の少ない他のページに影響を与えないように、データ使用量の多いウィジェットを別のページに配置します。 4. スクリプト化されたメニューアイテム サービスポータルの強力な機能であるスクリプト化されたメニュー項目は、表示するデータが多すぎたり、効率の悪いスクリプトが含まれていたりすると、パフォーマンスの問題を引き起こし、ポータル全体のページ読み込み速度を低下させる可能性があります。 サーバースクリプトと同様に、スクリプト化されたリストメニュー項目にも同様のパフォーマンスの問題と解決策があります。スクリプト化されたリストメニュー項目はポータル全体のページ読み込みに影響を与えるため、スクリプト化されたリストメニュー項目内の不適切なクエリは、単一のウィジェットインスタンス内よりも顕著になります。 5. 大容量のファイルおよび添付ファイルのロード 大きなファイルや添付ファイルの読み込みによっても、一般的なパフォーマンスの問題が発生します。例： 高解像度のメディアファイルを同時に読み込むと、読み込みに時間がかかることが予想されますが、それでもパフォーマンスに影響を与える可能性があります。sys_attachment テーブルに大きなフォントを繰り返し読み込むと、パフォーマンスに影響する可能性があります。CSS にエンコードされた画像を埋め込むと、HTTP リクエストの時間が長くなる可能性があります。 6. Record Watcher トラフィックの多いポータルページで Record Watcher を使用すると、適切に管理しないとパフォーマンスの問題が発生する可能性があります。具体的には、以下のようになります。 トラフィックの多いページで、範囲が広すぎるフィルターや静的フィルターを使用すると、サーバーコールバックが頻繁に発生する可能性があります。フィルターに一致するレコードの更新ごとにコールバックがトリガーされるため、多くのユーザーが使用するとセマフォが枯渇する可能性があります。フィルターを微調整することで、サーバー負荷を最小限に抑え、パフォーマンスの低下を防ぐことができます。 詳細については、「Fine-tuning record watchers in Service Portal」をご覧ください。Resolutionパフォーマンスの問題を診断するには、以下の手順を試してください。 1. SP ページパフォーマンス診断スクリプトを使用すると、ページの速度低下の原因となっているウィジェットを簡単に特定できます。 How to identify a slow widget on a pageも参照してください。 2. プラットフォーム UI でテストし、問題がポータル固有のものかプラットフォーム全体のものかを判断します。手順は次のとおりです。 「スクリプト - バックグラウンド」でクエリをテストします。クエリが遅い場合や大量のデータを返す場合は、サービスポータルウィジェットでも同様のパフォーマンスが得られます。 3. ブラウザによって処理が異なるため、別のブラウザで速度低下を再現できるか試してください。Internet Explorer には複数の既知の問題があるため、特に重要です。 4. ポータル内のすべてのページが遅いかどうかを確認します。以下の手順を試してください。 ヘッダーメニューで、スクリプト化されたリストに問題がないか確認します。テーマで大きなフォントや画像ファイルが読み込まれていないか確認します。すべてのポータルで1ページまたは複数のページの読み込みが遅い場合、テーマやスクリプト化されたメニュー項目がすべてのポータルで使用されていない限り、それらの項目が原因である可能性は低いでしょう。もしそうであれば、以下の手順を試してください。$spポータル（/$sp.do）でページを開きます。テーマやヘッダーメニューのないページが開きます。それでもページの読み込みが遅い場合は、ウィジェットに注目して、どのウィジェットが速度低下の原因になっているかを確認してください。 5. JavaScriptコンソールとブラウザ開発ツールのネットワークタブを確認します。速度低下の原因として考えられるのは以下のとおりです。 JavaScriptコンソールのエラー解決に時間のかかるHTTPリクエストが多数発生している注意: シングルページアプリケーションであるサービスポータルは、REST経由でサーバーと通信するため、リクエスト元を特定することが困難です。しかし、最も一般的なリクエストは、/api/now/sp/rectangle/ に sys_id が続くもので、これは通常、server.update() などを使用するウィジェットから送信されます。リクエスト内の sys_id は、呼び出し元のウィジェットインスタンスを識別します。 sys_id を知っておくと、トラブルシューティングに役立ちます。 6. Syslog テーブルで、大きな JSON オブジェクトに関する警告がないか確認してください。これは、ウィジェットが大きなデータセットを処理していることを示すことが多いです。警告が発生するのは次の場合です。 ポータルページの読み込み中速度低下の原因となるアクションの実行中 これらの警告は、ウィジェットが過剰なデータセットを扱っていることを示唆しており、データセットの削減などの最適化が必要になる可能性があります。Related Linksパフォーマンスの問題に関するトラブルシューティングの詳細については、次のブログ記事を参照してください。 インスタンスのパフォーマンスをトラブルシューティングする 5 つの方法クライアントスクリプトのパフォーマンスを向上させる 6 つの方法CChrome を使用してクライアントサイドのパフォーマンス低下のデバッグを実行する この記事は、ServiceNow コミュニティの投稿から作成されました。サービスポータルの 6 つの一般的なパフォーマンスの落とし穴とその回避方法