Profiling async await?
Hi,
I'm using dotTrace 5.5.4 trying to profile an application that makes heavy use of async await.
I'm wondering if there is a way to get relevant results using dotTrace since all the work being done async is "floating" somewhere and its time is not added to the actual call stack of my application?
Like my async call to the database takes ~10sec but I don't see these 10sec in the call tree for my work; the only metric that's added for it is a small amount of time from the framework where it's just dispatching the work off to another thread...
Please sign in to leave a comment.
Hello Peter,
dotTrace doesn't provide analysis for async/await. Sorry.
Kind regards,
Maria
But are there any plans to add support for it?
Hello Dmytro,
We keep the idea in mind, but this task is not high on our priority list.
Kind regards,
Maria
Hi guys,
any updates regarding async profiling?
Thanks
Hi Vitaliy,
Currently we don't have any special logic for async/await calls, but as far as I know there is no any issues with manual analysis of them. Have you experienced some issues with async/await?
Konstantin,
See my initial post. the issues (even if you could argue that it works "as designed") still persist, I would assume.
--> Profile runs of applications that rely heavily on I/O have completely uninterpretable results
Peter,
Because of technical realization of async/awaits asynchronous methods are not actually called from the method where task has been created. So these methods will not be shown under the actual parent method, but they will be present in call tree and could be analyzed. It is not very convenient, but anyway you will see these methods in Hot Spots/Top Methods sections if the methods have high time values.
If you have some code with completely uninterpretable results of profiling, could you please create a support ticket and attach example of the code and snapshot to it?
Konstantin,
Try profiling the simple console application as pasted here: http://pastebin.com/ei09Haqh
You will see that Task.WaitAll takes 7sec, but I'm unable to get a breakdown of that number. (In case of an async WCF operation I wouldn't even see that this scenario takes 7sec)
--> I'm unable to see that it's the method GetTheAnswerAsync that takes 7sec, and that 2 sec of that is spent on DoSomethingElseAsync
This is obviously a very trivial sample, but illustrates my point.
Peter,
You can't see that 2 seconds are spent in DoSomethingElseAsync() method because all Task.Delay() calls are executed on the same thread with the same call tree, one after another. And these calls are actually made not from GetTheAnswerAsync() and DoSomethingElseAsync() methods. Async/await work that way.
Konstantin,
I apologize for returning on the subject as Idon't want to go on and on about it, but I feel I'm not making my point clear enough perhaps.
This is just a sample, but translated to my reallife scenario: Let's say where there is Task.Delay right now, they are EF methods going to a db, e.g. "var persons = await Db.Persons.ToListAsync()", it would be the same situation.
I am aware that is how async await works, but that is also why the results in the dottrace snapshot are uninterpretable... If I don't know how much time is spent on a dbcall and (more important) how much percentage that call takes up in the context of my scenario, the results are unusable, I think.
Peter,
I see your point now. You're right, in your case some results in snapshot can be uninterpretable. Our team have discussed async/awaits one more time and it was decided to increase the priority of this task. We hope to implement it in the near future.
Thanks Konstantin!
Looking forward to see if it could be resolved, I know some other people that are waiting for this as well :)
I certainly am one of those "other people" waiting for this.
Dot Trace is incredible. I would love to see it get more support for Async / Await; I believe this is becoming the go to way to build dot-net applications, at least for me, and it would be helpful to have more readable profiling sessions.
Me too. Right now dottrace is of little use for async await code. I'll have to add profiling code manually for now.
Nvm, found that redgate ants supports "wall clock".
Hey Konstantin,
Is there any update on this?
Hi,
We are working on async/await support right now and plan to release it in the next release (2017.1).
Is it already in 2017.1.2? I can't see any changes.
Unfortunately no, async/await support will be released in 2017.2 version. Also it will be available in Early Access builds.
Any update on this? Async/await isn't really mentioned in dotTrace context in the blog post about the release: https://blog.jetbrains.com/dotnet/2017/06/07/resharper-ultimate-2017-2-eap-whats-new-build-1/
Hi,
Yes, async/awaits support for Timeline profiling mode will be released in 2017.2 version, but so far it is not available in EAP builds.
What about other profiling modes?
Unfortunately there are some issues with async/awaits support, so it will not be included to 2017.2 release. It will be available in 2017.3 EAP1. We are sorry about that, but we prefer not to release a poor-quality product.
We plan to add async/awaits support for other profiling types in 2018.1 version.
Added my vote. I see results using dottrace where < 1% of the time is accounted for in the trace. Meaning: to optimize my app, I need to figure out how to orchestrate the threads so it's waiting less and actually working more during the scope of the trace, but I can't see what's waiting on what, or how that affects the caller of the async requests.
@Konstantin Katsnelson, any ETA for 2017.3 EAP1? I have been updating through every single EAP of 2017.2 hoping to get this support!
Hi all,
Async/awaits support for Timeline profiling mode is available in EAP builds: https://www.jetbrains.com/resharper/eap/
Async/awaits support for Sampling/Tracing/Line-by-Line modes will be available in one or two weeks.
If you have any issues or thoughts - please let us know (in this topic or by clicking a "Submit a request" button in the upper right corner).