サービスポータルの 6 つの一般的なパフォーマンスの落とし穴とその回避方法Issue この記事の目的は、サービスポータルにおけるパフォーマンスの問題に影響を及ぼすいくつかのシナリオ、問題の診断方法、問題の回避方法について情報を共有することです。 目次 Internet Explorer自動リフレッシュウィジェット大規模なデータセットまたは非効率的なクエリを使用するサーバースクリプトスクリプト化されたメニューアイテム大容量のファイルおよび添付ファイルのロードRecord Watcherサービスポータルでパフォーマンスの問題を診断する方法 Internet Explorer Internet Explorer には、メモリ管理に関連する既知の問題がいくつかあります。これらが原因となって、サービスポータルでパフォーマンスの問題が発生する可能性があります。これらの問題、ならびに回避に関するベストプラクティスの詳細については、「 Internet Explorer 使用時にサービスポータルでのメモリリークを回避するためのベストプラクティス」を参照してください。 自動リフレッシュウィジェット 自動リフレッシュウィジェットにより、パフォーマンスに関する重大な問題が生じる可能性があります。これは通常、/sp/rectangle/ が多数呼び出された結果、セマフォが枯渇するという形で、インスタンス全体で見られます。 このトピックについては次のドキュメントで扱われています。自動リフレッシュするウィジェットが原因でインスタンスの処理速度が低下していますか？なおこの処理は、システムパフォーマンスに少なからず影響を及ぼします。 大規模なデータセットまたは非効率的なクエリを使用するサーバースクリプト ポータルのパフォーマンス低下を頻繁に引き起こす別の原因は、大量のデータ処理です。通常はウィジェットが使用されているページのロードで遅延が発生します。ただし、極端な場合はインスタンスのメモリ不足が発生します。この問題を回避するため、次の点を考慮してください。ユーザーが本当に確認しなければならないデータはどれほどありますか？例えば、ユーザーが確認したいのは、これまでに自分がオープンしたすべてのインシデントではなく、まだ処理が完了していないインシデントだけかもしれません。 大規模なデータセットの問題点 大規模なデータセットが問題になる理由はいくつかあります。 データのクエリ、ACL の評価、ビジネスルールの実行に時間がかかります。もちろん、これはポータルだけでなく、プラットフォーム全体に当てはまる要素です。データは $scope.data オブジェクト経由でコントローラーに送られます。このオブジェクトのサイズは、JSON エンコード、HTTP 経由の送信、ブラウザでの展開にかかる時間に直接関係します。データの反復処理が必要で、システムがそれぞれのレコードに何らかの処理を行う場合、CPU サイクルの点でコストが非常に高くなる可能性があります。普遍的に当てはまる点とはいえ、ポータルの設計においても注意してください。 大量のデータの処理を回避する最善の方法は何ですか？ フィルターを効果的に使用して、ユーザーが本当に必要とするデータのみを表示します。データの処理は可能な限り最小限にとどめます。大量のデータや処理が必要なウィジェットを、ポータル内の独立したページに分離します。こうすれば、あまり多くのデータを使用しない他のページは影響を受けません。 スクリプト化されたメニューアイテム スクリプト化されたメニューアイテムはサービスポータルで最も便利な機能の 1 つですが、ウィジェットのサーバースクリプトと同様、表示データが多すぎるとパフォーマンスの問題が発生することがあります。これらのスクリプトは、ユーザーがポータル内を移動するたびに実行されます。メニュー内に効率性の低いスクリプトが存在する場合、ポータルのすべてのページでロードが遅延する可能性があります。 ほとんどの状況で、この問題が発生する技術的な理由はサーバースクリプトの場合と同様であり、回避方法も同様です。これにより、ポータル上のすべてのページでロードのオーバーヘッドが増加します。つまり、スクリプト化されたリストのメニューアイテム内の不適切なクエリの影響をより迅速に (単一のウィジェットインスタンスよりも早く) 確認できるかもしれません。 大容量のファイルおよび添付ファイルのロード 顧客が大容量のファイルおよび添付ファイルのロードを行う際にも、頻繁にパフォーマンスの問題が発生します。多くの場合、これらのファイルは sys_attachment テーブルに格納されている高解像度のメディアファイルやフォントファイルです。サイズの大きい高解像度ファイルの場合、多少の時間がかかることをユーザー側も予期しているため、一般的には問題になりません。ただし、このようなファイルを多数読み込むポータルや、ポータルの各部で複数のフォントファイルが再読み込みされている場合は、問題視されることがあります。このような問題が生じる一例として、エンコードされた画像がページの CSS に埋め込まれている場合があります。ページを読み込む時、複数の異なる HTTP 要求への応答にこの CSS が含まれていれば、その処理に時間がかかる可能性があります。 Record Watcher ポータルページの Record Watcher がパフォーマンス低下の原因になる場合があることにも注意が必要です。フィルターの絞り込みが不十分だったり、トラフィックが多いページに静的フィルターを使用した Record Watcher を配置したりすると、トラブルの原因になりかねません。そのフィルターに一致するレコードを更新するたびに、サーバーへのコールバックがトリガーされるため、同じフィルターを監視しているユーザーが多数いる場合は、1 回の更新でセマフォが枯渇する可能性があります。それで、これらのフィルターをできる限り調整することが重要です。その方法の詳細については、次の記事を参照してください。サービスポータルでのレコード監視の微調整 サービスポータルでパフォーマンスの問題を診断する方法 SP ページのパフォーマンス診断スクリプトを使用する。これにより、ページの読み込み速度に悪影響を与えているウィジェットを非常に簡単に判断できます。 ページ上の遅いウィジェットを識別する方法 プラットフォームで試す。ポータルの動作が遅い場合は、プラットフォーム UI で試してください。多くの場合、ユーザーはサービスポータルでの動作が遅い理由のトラブルシューティングにかなりの時間を費やしますが、この問題が他の場所でも生じていることに気づいていないかもしれません。これにより、トラブルシューティングの方向性が大幅に変わる可能性があります。本当にポータル固有の問題なのか、それともプラットフォーム全体のパフォーマンスの問題なのかをすぐに判断することが重要です。 クエリをスクリプト – バックグラウンドで試してみてください。応答が遅い症状や大量のデータが返される症状の場合、サービスポータルウィジェットでも同じ現象が生じます。 別のブラウザを試す。ブラウザによって処理方法が異なる場合があるため、別のブラウザでも速度低下が発生するか確認します。Internet Explorer には既知の問題が多数あるため、Internet Explorer 使用時には特に重要です。 ポータルのすべてのページで速度低下が発生しているかどうかを確認する。上述の複数の問題について絞り込みを行うため、ポータル内のすべてのページで遅延が発生しているかどうかを確認します。すべてのページで遅延が発生しているのであれば、ヘッダーメニューを調べ、スクリプト化されたリストの問題を確認します。また、テーマで大きなサイズのフォントや画像ファイルがロードされているかどうかを確認してください。 どのポータルでも特定のページに速度低下が発生しているかどうかを確認する。すべてのポータルで特定のページやページグループのロードが遅延する場合、テーマやスクリプト化されたメニューアイテムが原因ではない可能性があります (すべてのポータルで同じものが使用されている場合を除く)。該当する場合は、$sp ポータル (/$sp.do) でページを開いてみてください。この方法ではポータルを経ずにページが開くため、ページ上にテーマやヘッダーメニューが表示されなくなります。それでもページのロードが遅い場合は、ページ上のウィジェットに注目し、どのウィジェットが速度低下の原因となっているかを調査します。 ブラウザのデベロッパーツールを見る。JavaScript コンソールと [ネットワーク] タブの 2 か所を確認します。JavaScript コンソールにエラーがある場合、このエラーが速度低下の原因になっている可能性があるため、さらに調査を進めることができます。また、多数の HTTP 要求や、1 つまたは複数の HTTP 要求の解決に時間がかかっている場合もあります。該当する場合は、それらに着目して調査を始めることができるでしょう。 HTTP 要求に関する注意：サービスポータルはシングルページアプリケーションであり、サーバーとの通信のほとんどが REST 経由で行われます。これにより、要求元の特定が困難になる場合があります。最も一般的な要求として、/api/now/sp/rectangle/ の後にいくつかの sys_id が続くというものがあります。これは、server.update() または同様の関数経由でサーバーを呼び出すウィジェットに由来します。その sys_id が、要求を行うウィジェットインスタンスです。このことを覚えておくと、速度低下の原因になっているウィジェットを迅速に判別できます。 syslog テーブルを確認する。JSON オブジェクトのサイズが大きいことが原因で速度低下が発生している場合、syslog テーブルに JSON オブジェクトのサイズに関する警告が作成されることがあります。ポータルページがロードされたとき、または速度低下の原因となっているアクションを実行したときにこれらの警告が表示される場合は、いずれかのウィジェットが非常に大きなデータセットを処理しており、調整する必要があることを示しています。Related Linksパフォーマンスの問題に関するトラブルシューティングの詳細については、次のブログ記事を参照してください。 インスタンスのパフォーマンスをトラブルシューティングする 5 つの方法クライアントスクリプトのパフォーマンスを向上させる 6 つの方法CChrome を使用してクライアントサイドのパフォーマンス低下のデバッグを実行する この記事は、ServiceNow コミュニティの投稿から作成されました。サービスポータルの 6 つの一般的なパフォーマンスの落とし穴とその回避方法