I'm working with Dynamics CRM 2016, i have developped specified plug_ins.
On my first test, my process stay so long that time out exception is displayed.
I optimized my code, reorgonized my plug_ins, than i test for the second time. It's now more performant but i need some measures or statics.
I have been told to use Benchmark but i couldn't find any use documentation.
Please help me to integrate Benchmark in my Dynamics CRM 2016 process, i'm stucked here.
Not sure what Benchmark is, but you can debug your plugins locally using the plugin registration tool kit, or you can add trace statements and provide your own timings to figure out what is taking so long.
My best guess is that you're running on the update of an entity, and updating the entity, which in turn is causing your plugin to trigger again, updating the entity, which in turn is causing your plugin to trigger again, updating the entity... infinite loop that then gets shut down after 2 minutes by CRM.
Also, in addition to what Daryl said, make sure you aren't pulling so many records at once as there is maximum allowed execution time for each query.
Try to use server side pagination whenever possible. And limit the number of columns / attributes to the really minimum you actually need.
If you are using an OnPrem, you could use SQL Monitor for that, like, find out if you have any locks, long queries, etc...
With some SQL Execution Plan magic and some patience you could improve any bottlenecks there, and get query execution times too.
Now, if that is a CRM online, you'll be more limited as to whether what you can monitor.
Good luck!
In CRM 2016 when you use ITracingService.Trace the output is written inside the Plugin Trace Log entity (activate this in System Settings, the entity itself is found in the Settings area).
You can simply use tracing to write something (i.e. "START" at the beginning of the Execute method and "END" at the end), then look at the Plugin Trace Log entity which (like all entities) has createdon field.
On a side note, when benchmarking a plugin becomes desirable one should most likely make it faster instead (if a plugin takes 2 seconds to run, benchmarks become irrelevant)
