Dynamics crm 2011 从插件中调用ExecuteMultipleRequest是否有益？

我知道，当从CRM外部执行批量更新时，是一个巨大的性能提升器。我不知道从CRM插件中调用它是否有益

我目前的理解是，使用ExecuteMultipleRequest获得的主要性能收益是实际的SOAP消息传递成本。因此（为了更新5000条记录），您可以只发送一条包含5000条记录的消息，而不是发送5000条单独的Soap消息（每条消息都必须被序列化、验证、传输等）。但是当从插件调用时，您已经在服务器上，因此不需要进行SOAP调用，因此使用它没有任何好处

---

还有其他我没有看到的潜在好处吗？

所以我做了我以前应该做的事情，并创建了一个插件来测试这一点。这是在CRM 2013上在我的本地虚拟机上运行的（预操作），因此结果可能会有所不同，但我看到普通的旧创建每100个实体减少约290ms

我首先创建了这个插件

公共类ExecuteMultipleTester:插件库
{
受保护的覆盖void ExecuteInternal（Common.Plugin.localpluginotext pluginotext）
{
var watch=新秒表（）；
var service=pluginotext.OrganizationService；
watch.Start（）；
var request=新的ExecuteMultipleRequest
{
设置=新的ExecuteMultipleSettings
{
ContinueOnError=false，
ReturnResponses=false，
},
请求=新的OrganizationRequestCollection（）
};
对于（变量i=0；i<100；i++）
{
request.Requests.Add（新建CreateRequest
{
目标=新的一年
{
新年=i+“-B”，
new_YearIntValue=i，
}
});
}
执行（请求）；
看，停；
var multipleCreate=watch.elapsedmillisons；
watch.Restart（）；
对于（变量i=0；i<100；i++）
{
服务。创建（新的一年）
{
新年=i+“-A”，
new_YearIntValue=i，
});
}
看，停；
抛出新的InvalidPlugineExecutionException（String.Format（“ExecuteMultipleRequest时间为：{0}毫秒，标准为：{1}毫秒”，multipleCreate，watch.ElapsedMilliseconds））；
}
}

注册插件并运行了10个测试。以下是结果（ASCII表格，哦，耶！）：

因此，从这些结果来看，不需要在插件中执行ExecuteMultipleRequest。您已经在服务器上，必须执行更多代码才能执行相同的操作

更新1-1000针对完整环境创建测试 为了创建1000条记录，我再次运行了这个测试，并且是在一个完整的环境中，为SQL、服务和Web设置了单独的框。非常相似的结果（只进行了5次测试，因为这需要更长的时间）

有趣的是，对于10倍以上的记录，时间大约延长了25倍，但差异仅为12倍以上。（尝试进行更新，而不是删除，但我不断收到超时错误，即使每次只有一个…一定是在创建某种无限循环，只是不确定是什么…）

---

对于1000辆车来说，速度要慢4秒。我不会在我的插件中使用它…

这些类型的结果与我在一体机上运行测试时看到的结果一致（即CRM服务器、SQL……都包含在一台机器中）。当运行一个更传统的部署时，我看到了相反的结果。此外，随着更多的消息添加到您的请求中，差距也会显著扩大。考虑将循环增加到进程300, 500或1000（默认为执行Excel MultIpRerErrQuestMax），并将一个将CRM前端、CRM ASYNC和SQL Server分离到不同的盒子上的部署运行。

< P>我知道这是一个老问题/答案，但自从我在研究中发现了这一点，我想我也应该加入我在MSDN上找到的一些信息：

限制并发调用–适用于Microsoft Dynamics 365（联机） 每次执行的并发执行次数限制为2次 组织机构。如果超过该限制，则会出现

服务器忙

故障 在执行第一个请求之前抛出。对于内部部署 部署时，默认情况下不启用限制

---

基于此，我建议在任何情况下都不要使用

ExecuteMultipleRequest

，初始数据加载场景除外

uhm，假设您正在更新插件中的5000条记录，在某些情况下使用ExecuteMultipleRequest可能会在2分钟限制之前完成（现在想想可能不是个好主意。我可能会把问题改成一个工作流），是否会比5000次单独更新快？如果是，原因是什么？沙箱中的工作流具有相同的2分钟限制。关于ExecuteMultipleRequest，Microsoft在MSDN

n general上写道，ExecuteMultipleRequest的行为与您单独执行输入请求集合中的每个消息请求的行为相同，但具有更好的性能性能

@GuidoPreite显然，当从客户端执行时，它应该被编辑为具有更好的性能。我的测试表明，它在插件中的运行速度较慢。如果在插件中使用，请参阅相关链接以了解其他可能的故障副作用。一个失败，它们都失败了。感谢您做了这个实验。我对答案发表了评论前几周声明在插件中使用ExecuteMultiple是没有必要的（），我一直担心我没有真正证明我所说的。现在证据已经很清楚了。我很好奇，如果你使用更多的c，是否会得到同样的结果

+------------------+---------------+-------+
| 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 |
+------------------+---------------+-------+

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