Is it useful to call ExecuteMultipleRequest from inside the plugin?

Question

I know that ExecuteMultipleRequest is a huge performance enhancer when doing batch updates from outside CRM. What I do not know is that it is useful to call it from the CRM plugin.

My real understanding is that the main performance gain from using ExecuteMultipleRequest in the actual cost of SOAP messages. Therefore (to update 5000 records) instead of sending 5000 separate Soap messages (each of which must be serialized, authenticated, transmitted, etc.), that all of them should be sent to the server, you can send only one message with 5000 records. But when you call from the plugin, you are already on the server, so SOAP calls should not be made, and therefore there is no use for using it.

Are there any other potential benefits that I do not see?

Answer 1

So, I did what I had to do before, and just created a plugin to test this. This works on CRM 2013 on my local virtual machine (Pre-Operation), so the results can change, but I see a simple old Create, which takes about 290 ms less than 100 objects

I created this plugin first

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)); } } 

I registered the plugin and performed 10 tests. Here are the results (ASCII tables, oh yah!):

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

Thus, from these results, there is no need to execute ExecuteMultipleRequest from within the plugin. You are already on the server to execute another code to perform the same operation.

Update 1 - 1000 Creates a full environment test.

I ran this test again to create 1000 records and in a full-fledged environment with separate blocks for SQL, Services and Web. Very similar results (only 5 tests, since they took much longer)

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

The time was interesting when 10 times more time was 25 times more, but the differences were only 12 times more. (Trying to make updates, not delete, but I kept getting timeout errors, even for one of them ... There must be some kind of endless loop, just not sure what ...)

For 1000 creates, almost 4 seconds slower. I would not use it in my plugins ...

Answer 2

This type of result is consistent with what I saw when running tests on all in one field (that is, on a CRM server, SQL, ... everything contained on one machine). When you work against a more traditional deployment, I see that these results are reversed. In addition, the gap widens significantly as more posts are added to your request. Think about how to increase your cycle to process 300, 500, or 1000 (the default maximum level for ExecuteMultipleRequest) and run it against a deployment that split CRM Front End, CRM Async, and SQL servers into different blocks.

Answer 3

I know this is an old question / answer, but since I found it in my research, I thought that I would also listen to some information that I found on MSDN:

Throttling concurrent calls — For Microsoft Dynamics 365 (online), there is a limit of 2 concurrent executions of ExecuteMultipleRequest per organization . If this limit is exceeded, a Server Busy error is thrown before the first request is executed. For ease of deployment, throttling is not enabled by default.

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

Based on this, I would recommend that you never use ExecuteMultipleRequest under any circumstances other than source data loading scripts.