私たちが現在使用しているCMSはかなり混乱しているため、上司から、市場で入手可能なCMSについて調査するように依頼されました。
.NET 開発者である私にとって、拡張性と .NET 環境およびよく知られたツールとの完全な統合により、Dynamics CRM を選択して実装することは素晴らしいことです。
すべてのマーケティングは素晴らしいように聞こえますが、このシステムに関する一般的な欠点、問題について知りたいです。
最も重要なのは、約 150 人の同時ユーザーと非常にアクティブなユーザーがいる企業でのパフォーマンスです。競合他社のシステムに比べて非常に遅いと聞きました。
Dynamics CRM 製品チームは、500 人の同時ユーザーのガイダンスとベンチマークを含む優れたホワイトペーパーを公開しました。この論文を勉強することで、多くのことを学ぶことができます。リンクはこちら：
主要な競合他社との比較について、私は実際にアドバイスを提供することはできません. 主なことは、安価で非常に積極的に開発されていることです。
パフォーマンスについては少し言えますが、役立つかもしれません。
システムを使用する同時ユーザー数は約 400 ～ 600 人です。このシステムは特に Web サーバーを集中的に使用するわけではありません。弾力性のために 2 つあり、オフラインになると大変なことになりますが、これらのサーバーに課税されることはありません。いくつかの仮想コアと 4 ギガの RAM があります。
当社のデータベースのサイズは 130 GB で、48 GB の RAM を搭載した 24 コアのデータベース サーバーでホストされています。クラスター化されていますが、SQL サーバーは 2 つのアクティブなノードを処理できないため、アクティブなサーバーは 1 つだけです。
データベース サーバーは、実際には限界に達することはありません。ただし、必要な非常に重要な変更が 1 つあります。これは、大規模な CRM インストールのすべてのユーザーに今すぐ行うよう MS がアドバイスしていると思われる変更です。デフォルトでは、SQL Server には、行が読み取られているときにデータベースへの書き込みをブロックするロック モードがあります。私たちのシステム (および明らかに他の多くのシステム) では、それが大きな問題を引き起こしていました。
別のモード（「スナップショット分離」と呼ばれていると思います）またはそのようなものをオンにしました。公平を期すために、200 人の同時ユーザーがいたとしても、Activitypointer や account などのより中心的なテーブルがかなり大きくなるまで (数百万)、問題にはなりません。
したがって、適切なハードウェアがあり、SQL Server を理解している人がいる限り、CRM 2011 が多くのユーザーを処理できることは間違いありません。
HTH
S
ユーザー数/アクティビティについてはお答えできません。SDK の記事「パフォーマンスのベスト プラクティス」を参照できます。プラグイン (データ アクセス メッセージ用) の作成、CRM Web サービスへのカスタム ページのアクセス、SSRS レポートの作成を担当する側に話をします。私が関連できるいくつかのポイント：
プラグインを無効にします。これは、CRM への魅力的で主要な統合ポイントです。彼らがそれをパフォーマンスの問題として挙げているという事実は、がっかりしています。プラグイン キャッシュに起因する OutOfMemory 例外が確認されています。データベースではなくディスクにデプロイすることで、この問題を回避しました。データベースでは、アセンブリをリロードし、プラグインが呼び出されるたびに署名を確認します。これにより、Large Object Heap が消費されていたと考えられます。おそらく、通常の CRM 実装では問題になりません。
取得データの制限。絶対。余分な結合が発生するため、必要のないルックアップ/ピックリスト/ビットはできるだけ避けてください。小規模なエンティティでは大したことにはなりません。ただし、多数の属性を持つエンティティが必要な場合は、そうなる可能性があります。おそらく、通常の CRM カスタマイズでは問題になりません。それ以外の場合の適切な設計では、この問題を回避する必要があります。