Hard to profile cpu and memory on ravendb.client losing the stacktrace due to socket async operations

[valeriob]

Hi,
I'm running ravendb 5.1 both server and client, I'm trying to diagnose what is the root cause of a lot of gc happening, I found that it's due to the queries that I make, but due to how ravendb client is implemented i'm having an hard time to follow both cpu profilers stack traces and memory profilers roots.

[ayende]

That is just the nature of working with async, I'm afraid.
At a glance, it looks like you are reading a lot of documents?

What is it that you are actually doing here?
And are you concerned about memory utilization, amount of allocations or total GC time?

[valeriob]

Hi,
yea i'm trying to find out what query is it :D I think i nailed it down thanks to ravendb traffic watch, since I was able to reproduce the issue in a subsystem, but i usually run dottrace and dotmemory or perfview in production, and i can instantly pinpoint the issue :D Now i feel blind :(
Do you think will be possible in the future to have back the whole stack trace that originated the query ?

[ayende]

I would dearly love to be able to do that, but that depends on the .NET team, to be honest, or on JetBrains being smart enough to follow the async trace.

From our perspective, the I/O is async, (has to be), so we have to deal with it.