6

CRM の外部からバッチ更新を実行する場合、 ExecuteMultipleRequestがパフォーマンスを大幅に向上させることはわかっています。私が知らないのは、CRM プラグイン内から呼び出すことが有益かどうかです。

私の現在の理解では、ExecuteMultipleRequest を使用することによる主なパフォーマンスの向上は、実際の SOAP メッセージング コストにあるということです。したがって、(5000 レコードを更新する場合) 5000 の個別の Soap メッセージ (それぞれをシリアル化、認証、転送などする必要がある) を送信するのではなく、すべてをサーバーに送信する必要があり、5000 レコードを含むメッセージを 1 つだけ送信できます。ただし、プラグインから呼び出された場合は、既にサーバー上にいるため、SOAP 呼び出しを行う必要はありません。したがって、SOAP を使用する利点はありません。

私が見ていない他の潜在的な利点はありますか?

4

3 に答える 3

9

そのため、以前に行うべきことを行い、これをテストするためのプラグインを作成しました。これは私のローカル VM の CRM 2013 で実行されているため (操作前)、結果は異なる可能性がありますが、単純な古い Create は 100 エンティティあたり約 290 ミリ秒短縮されています。

私は最初にこのプラグを作成しました

public class ExecuteMultipleTester : PluginBase
{
    protected override void ExecuteInternal(Common.Plugin.LocalPluginContext pluginContext)
    {
        var watch = new Stopwatch();
        var service = pluginContext.OrganizationService;

        watch.Start();
        var request = new ExecuteMultipleRequest
        {
            Settings = new ExecuteMultipleSettings
            {
                ContinueOnError = false,
                ReturnResponses = false,
            },
            Requests = new OrganizationRequestCollection()
        };

        for (var i = 0; i < 100; i++)
        {
            request.Requests.Add(new CreateRequest
            {
                Target = new new_Year
                {
                    new_Year = i + "- B",
                    new_YearIntValue = i,
                }
            });
        }
        service.Execute(request);
        watch.Stop();

        var multipleCreate = watch.ElapsedMilliseconds;

        watch.Restart();
        for(var i = 0; i < 100; i++)
        {
            service.Create(new new_Year
            {
                new_Year = i + "- A",
                new_YearIntValue = i,
            });
        }
        watch.Stop();

        throw new InvalidPluginExecutionException(String.Format("ExecuteMultipleRequest Time was: {0}ms, Standard was: {1}ms", multipleCreate, watch.ElapsedMilliseconds));
    }
}

プラグインを登録し、10 個のテストを実行しました。結果は次のとおりです (ASCII テーブル、ああそう!):

+------------------+---------------+-------+
| Execute Multiple | Sevice.Create | Diff  |
+------------------+---------------+-------+
| 777              | 408           | 369   |
| 493              | 327           | 166   |
| 614              | 346           | 268   |
| 548              | 331           | 217   |
| 577              | 312           | 265   |
| 675              | 313           | 362   |
| 574              | 318           | 256   |
| 553              | 326           | 227   |
| 810              | 318           | 492   |
| 595              | 311           | 284   |
+------------------+---------------+-------+
|                    Average Diff: | 290.6 |
+------------------+---------------+-------+

これらの結果から、プラグイン内から ExecuteMultipleRequest を実行する必要はありません。既にサーバー上にいるため、同じ操作を実行するにはさらにコードを実行する必要があります。

更新 1 - 1000 完全な環境に対するテストを作成します

1000 件のレコードを作成するためにこのテストを再度実行し、SQL、サービス、および Web 用に個別のボックスを備えた本格的な環境で実行しました。非常によく似た結果 (時間がかかっていたため、5 つのテストのみを実行しました)

+------------------+----------+--------+
| Execute Multiple | Standard |  Diff  |
+------------------+----------+--------+
|            18922 | 15057    | 3865   |
|            18668 | 14946    | 3722   |
|            18162 | 14773    | 3389   |
|            19059 | 14925    | 4134   |
|            18334 | 15306    | 3028   |
+------------------+----------+--------+
|                  | Average  | 3627.6 |
+------------------+----------+--------+

興味深いことに、10 倍の記録に対して時間は約 25 倍長くなりましたが、差は 12 倍に過ぎませんでした。（削除ではなく更新を試みましたが、タイムアウトエラーが発生し続けました。それぞれに1つだけでも...何らかの無限ループを作成していたに違いありません...）

1000 の作成では、ほぼ 4 秒遅くなります。プラグインでは使用しません...

于 2015-02-09T20:09:13.190 に答える
0

これは古い質問/回答であることは承知していますが、調査で見つけたので、MSDN で見つけた情報も参考にすると思いました。

同時呼び出しの調整 – Microsoft Dynamics 365 (オンライン) の場合、組織ごとにExecuteMultipleRequestの同時実行は 2 回に制限されています。その制限を超えると、最初のリクエストが実行される前にフォルトがスローされます。オンプレミス展開の場合、スロットリングはデフォルトで有効になっていません。Server Busy

https://msdn.microsoft.com/en-au/library/jj863631.aspx#limitations

これに基づいて、初期データ ロード シナリオを除いExecuteMultipleRequestて、いかなる状況でも決して使用しないことをお勧めします。

于 2017-09-11T01:45:23.757 に答える
0

これらのタイプの結果は、オールインワン ボックス (つまり、CRM サーバー、SQL、... すべてが 1 つのマシンに含まれている) でテストを実行したときに見た結果と一致しています。より伝統的な展開に対して実行すると、それらの結果が逆になることがわかりました。また、リクエストに追加されるメッセージが増えると、ギャップが大幅に広がります。ループを増やして 300、500、または 1000 (ExecuteMultipleRequest の既定の最大値) レコードを処理し、CRM フロント エンド、CRM 非同期、および SQL サーバーを別々のボックスに分離した展開に対して実行することを検討してください。

于 2015-02-13T13:38:24.450 に答える