In Dynamics plugin implementations, you might have lengthy complex plugins that makes calls to Dynamics several times. I agree that calls to Dynamics should be as less as possible and use Link Entity as much as possible and the plugin should be well designed to handle such lengthy executions.
However, there are instances where these plugins are probably updating some fields that in-turn trigger some other sync processes and the execution begins to take longer than it should.
At times, such lengthy executions result in the plugin timing out. In case of Dynamics 365 Online, the timeout is 2 minutes and you can’t change it. (In on-premise, you can)
And now, you need to know what’s taking so long! So I want to propose a method which proved effective for me to identify this.
First, in case you are looking to work with Tracing for plugins, here’s a great blog on the same – Debugging Your Plug-ins with the Plug-in Trace Log
Add DateTime to Trace Logs
One of the best approaches to identify what portion of the plugin execution is actually taking time to process is to keep adding Trace logs and that too, with a timestamp!
This will give you an idea of what part of your plugin is taking long to execute and will give you a fair idea if anything needs to be redesigned.
Set these traces at the very beginning of your plugin and at all necessary places as well as the very end to cover execution cycle well.
And your logs will actually record the time when that operation was hit.
So now, you have an idea of how the 2 mins are spent and maybe start troubleshooting in that direction.
Hope this quick tip helps!
D365 Demystified 