Freigeben über

Dynamics CRM 2015 パフォーマンスの公開ドキュメント その 1

  • Artikel

みなさん、こんにちは。

Dynamics CRM をご利用のお客様からパフォーマンスに関する問い合わせを多くいただきます。
パフォーマンスは利用者の利便性に直結する非常に重要な項目です。

ダウンロードセンターには、Dynamics CRM 2015 においてパフォーマンスの問題が発生する
主な原因とそれらを考慮したうえで実施するデザインパターンを解説している文書が公開されています。
非常に重要な内容のため、複数回にわたり文書の内容を紹介していきたいと思います。

この文書は Dynamics CRM 2015 、Dynamics CRM 2013 を対象とした内容です。

Microsoft Dynamics CRM 2015 Performance and Scalability Documentation（英語）：
https://www.microsoft.com/en-us/download/details.aspx?id=45905

はじめに

パフォーマンスの問題を語る上で重要なポイントが 2 つあります。
- カスタマイズや開発することにより ユーザー操作に影響を与える作りこみができる
- 競合が発生した場合、ロックやトランザクションの仕組みによりシステムを保護している

開発者は、パフォーマンスの問題を引き起さないようどういった問題が発生するのか
理解する必要があります。また、ロックやトランザクションは、システムを保護するために
発生している場合があることを理解する必要があります。

一般的な事象

パフォーマンスの問題の多くは、以下に示す一般的な事象によりが複合的に発生する場合が多いです。

1. 遅いレスポンス

特定の場所のレスポンスが遅い（例：フォーム、ビュー）。

2. Generic SQL errors

データベースにて "Generic SQL Error" や ”SQL timeout” が記録される。
これらのエラーはほとんどの場合、アクションが必要となる。

3. デッドロック

プラットフォームのエラーとして記録され、発生するとリクエスト処理は強制的にロールバックされる。

4. スループットの制限

負荷の高いバッチが展開されており、それによりスループットが非常に遅くなる。

これらの事象は、ディスク I/O の制約、製品の不具合でも同様の問題が発生する場合があります。

主な原因

一般的な事象の多くは長時間のトランザクション処理により引き起こされます。
例えば、複雑なクエリや同じリソースへの並列処理によりブロックが発生し、
長時間のトランザクション処理となり、ユーザーへの応答時間の遅延や
タイムアウトを引き起こす可能性があります。

1. 遅いレスポンス ＞ 複雑なクエリ ＞ ブロック ＞ 長時間のトランザクション
2. タイムアウト ＞ 複雑なクエリ ＞ ブロック ＞ 長時間のトランザクション
3. デッドロック ＞ 同じリソースへの並列処理 ＞ ブロック ＞ 長時間のトランザクション
4. 低いスループット ＞ ブロック ＞ 長時間のトランザクション

プラットフォームの制約

Dynamics CRM は、ユーザー操作による重大な影響を防ぐためいくつか制約を設けています。

プラグインのタイムアウト: 120 秒（既定値）

プラットフォームやサンドボックスサービスの保護および、ユーザーの利便性を妨げないよう、
プラグインは長時間実行しないよう設計されています。

SQL タイムアウト: 30 秒（既定値）

リクエスト対象である特定の組織やデータベースや、サーバーで共有しているリソースを
保護するため実行時間に制限があります。

ワークフローの制限

特に静的な制約はありませんが、同じ展開内に複数の組織を展開している場合、
ワークフローを実行するためのリソースは共有されているため、
すべての組織のパフォーマンスに影響があります。

最大同時接続数: 100

Web サーバーの IIS からデータベースに対する同時接続数は、最大 100 までです。
もしこの上限を超過した場合、既存の接続がブロックされている原因を調査する必要があります。
複数の Web サーバーを利用している場合、標準的なデータベースに対して、
100 の同時接続で各 Web サーバーのスループットが 1000 リクエストに対して 10 ms 未満と
なることを想定しています。

ExecuteMultiple の最大同時実行数: 2

ExecuteMultiple メソッドは、外部からまとめて複数のメッセージを一括で送信することができます。
大規模な処理の場合、ユーザーの応答時間が犠牲になる可能性があるため、
1 つの組織あたりの最大同時実行数は 2 つまでに制限されます。
ロードバランサーにより複数の Web サーバーが実行されている環境では、
それ以上に設定することも可能ですが、オンライン環境のようなインフラの制御ができない場合、
2 に設計されることが安全です。

これらの制約は、Dynamics CRM Online / 設置型ともに適用されています。

まとめ

今回は、Dynamics CRM のパフォーマンス問題を理解するうえで必要な、
一般的な事象とその原因を紹介しました。また、Dynamics CRM が設けている制約も
押さえておく必要があります。次回は、具体的にどのような仕組みで問題が発生しているか
ロックとトランザクションにフォーカスして紹介していきます。

- プレミアフィールドエンジニアリング 河野 高也

Comments

  • Anonymous
    September 10, 2015
    お世話になっております。 上記記事にて Web サーバーの IIS からデータベースに対する同時接続数は、最大 100 までです。とありますが ある特定の時間にCRMのIISのサイトに接続されているセッション数（ユーザ数）を確認する方法はありますでしょうか。 IISのログから確認できるなどありましたご教示いただけないでしょうか。 お手数をおかけいたしますが よろしくお願いいたします。 以上

  • Anonymous
    September 13, 2015
    コメントいただきありがとうございます。 ご質問のCRM サイトに接続しているユーザー数を確認する機能は提供しておりません。 参考になる情報として、IIS サーバーのパフォーマンスカウンター「Web Service - Current Connections」により、アクティブなTCP/IP セッション数を確認することが可能です。 また、プロキシサーバーを経由していない場合は、IIS ログの接続元がユーザー数の目安になるかと思います。

  • 河野 高也

  • Anonymous
    September 28, 2015
    返信が遅くなってしまい申し訳ありません。 ご回答いただきありがとうございました。 CRMの使用状況を把握したかったのですが、ご教示いただきましたパフォーマンスカウンターの中に 「Web Service - Current Connections」以外にも「CRM Server」の「Total Organization Service Requests」という カウンターが存在しました。こちらでユーザの要求数が確認できそうですが如何でしょうか？ よろしくお願いいたします。 以上

  • Anonymous
    September 28, 2015
    CRM の組織 Web サービスに対する「要求数」を集計したい場合、ご指摘されたカウンターが参考になります。該当のカウンターには要求が成功したかに関わらずすべての要求が含まれます。 一方、前回の「ユーザー数」を確認する場合、セッション数や要求元から判断する必要があります。 集計されたい目的にマッチしたカウンターを選択いただければと思います。