パフォーマンスのための設計パート 1

[JunshuO]

パフォーマンスのための設計をテーマにした最近の ServiceNow ウェビナーで得た素晴らしい情報をいくつかお届けしたいと思います。ServiceNow のアカウントエスカレーションエンジニアリング (AEE) チームの Haret Valean 氏と Jon Gittoes 氏に感謝します。これらは、SN インスタンスのパフォーマンスが著しく低下し、対処に困惑する際に根本原因にたどり着く人々です。ヒントとしては...その原因は多くの場合、利用者側の要因です。しかし、私たちがよりよく知れば、私たちはより良いパフォーマンスを実現できますよね。

これはマルチブログシリーズになるかもしれませんが、最初のトピックに取り組みましょう。

高レベルのアーキテクチャは次のように説明できます。HTTPリクエストがSNのファイアウォールに到達し、アプリケーション配信コントローラー (ADC) を介して処理され、複数のアプリケーションノードにルーティングされた後、データベース層と連携します。すべての SN インスタンスに少なくとも 2 つのアプリケーションノードがあります。各ノードには、2 GB のヒープ領域 (メモリ)、作業を実行できるスレッドのプール、および 1 つ以上のデータベース接続プールを持つ JDBC ドライバーがあります。

AEEチームは、SNインスタンスアーキテクチャにおいて共通するボトルネックをどこで特定していますか。

1 つ目はプライマリ データベースです。データベースの速度が遅いと、インスタンス全体に影響を与える可能性があります。これは、通常、プライマリ データベースが単一の共有リソースであり、過剰なトランザクション (CPU / IO / 履歴リストの長さ) によって圧倒される可能性があるためです。この種の問題を軽減するにはどうすればよいでしょうか。1つは、OR 条件と CONTAINS 演算子をできるだけ避けて、最適化のためのクエリーを定式化することです。また、テーブルが適切にインデックス化されていることを確認します。インデックス付き列に対するクエリは、インデックスのない列よりも非常に高速に実行されます。パフォーマンスの問題のトラブルシューティングを開始し、トランザクションの SQL 応答時間にスパイクまたは異常に高い傾向が見られる場合は、次の点を探す必要があります。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/designing-for-performance-part-1/ba-p/3177582。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/designing-for-performance-part-1/ba-p/3177582。

[JunshuO]

パフォーマンスのための設計をテーマにした最近の ServiceNow ウェビナーで得た素晴らしい情報をいくつかお届けしたいと思います。ServiceNow のアカウントエスカレーションエンジニアリング (AEE) チームの Haret Valean 氏と Jon Gittoes 氏に感謝します。これらは、SN インスタンスのパフォーマンスが著しく低下し、対処に困惑する際に根本原因にたどり着く人々です。ヒントとしては...その原因は多くの場合、利用者側の要因です。しかし、私たちがよりよく知れば、私たちはより良いパフォーマンスを実現できますよね。

これはマルチブログシリーズになるかもしれませんが、最初のトピックに取り組みましょう。

高レベルのアーキテクチャは次のように説明できます。HTTPリクエストがSNのファイアウォールに到達し、アプリケーション配信コントローラー (ADC) を介して処理され、複数のアプリケーションノードにルーティングされた後、データベース層と連携します。すべての SN インスタンスに少なくとも 2 つのアプリケーションノードがあります。各ノードには、2 GB のヒープ領域 (メモリ)、作業を実行できるスレッドのプール、および 1 つ以上のデータベース接続プールを持つ JDBC ドライバーがあります。

AEEチームは、SNインスタンスアーキテクチャにおいて共通するボトルネックをどこで特定していますか。

1 つ目はプライマリ データベースです。データベースの速度が遅いと、インスタンス全体に影響を与える可能性があります。これは、通常、プライマリ データベースが単一の共有リソースであり、過剰なトランザクション (CPU / IO / 履歴リストの長さ) によって圧倒される可能性があるためです。この種の問題を軽減するにはどうすればよいでしょうか。1つは、OR 条件と CONTAINS 演算子をできるだけ避けて、最適化のためのクエリーを定式化することです。また、テーブルが適切にインデックス化されていることを確認します。インデックス付き列に対するクエリは、インデックスのない列よりも非常に高速に実行されます。パフォーマンスの問題のトラブルシューティングを開始し、トランザクションの SQL 応答時間にスパイクまたは異常に高い傾向が見られる場合は、次の点を探す必要があります。