Open dazbradbury opened 4 months ago
Just to note, that this information does exist, if TrackConnectionOpenClose
is set to true, then the connection close event clearly happens after the sql - ExecuteReader
. It's more that when you look at the aggregated view that context is loss / hard to interpret. Here is a more extreme example, where it takes 60s to transfer the data:
But you can see the aggregated view hides the fact the SQL call took 60s:
So I just tested comparing ProfiledDbConnection
(docs) vs. AddEntityFramework
(docs) and it does seem they behave differently:
The only documentation I can see around profiling SQL is here: https://miniprofiler.com/dotnet/HowTo/ProfileEFCore, and here https://miniprofiler.com/dotnet/HowTo/ProfileSql. It's not clear if these two approaches are equivalent, but the following issue uses the former.
The documentation does not specify what to expect if you have a "fast" SQL query which spends a lot of time transferring data accross the network.
For example let's say we run:
Within a code block like:
This is a simple query, which SQL quickly runs, and Miniprofiler sat on an instance right next to the DB would show a total time close to the query time.
Now let's say we're hundreds of miles away from the DB. The time it takes to run the query on SQL server is still fast, but the overall query time including network transit is slow.
Where would you expect MiniProfiler to allocate that time? As far as I can tell, it does not appear in the SQL time, but makes it appear like the object materialisation is taking up the time:
If I run the exact same SQL query from SQL Server Management Studio, it takes several seconds (not 20ms).
Ideally we could separate out SQL query time from SQL network time, but failing that should the documentation be clearer on what time is being calculated and returned here?