When the Real-Time View is open, ORM Profiler performs real-time analysis on the data received and viewed in the Real-Time View. This real-time analysis is a subset of the existing set of analysis options available on a snapshot. By default the recommended analysis functions are enabled with default arguments.
To specify different arguments and enable different / more analysis functions, click the Real-Time Analysis Settings button on the Home tab or on the Real-Time View tab.
When an analysis function is triggered, it assigns an Alert to the element which triggered the analysis function, e.g. a command or a connection. Alerts (and exceptions) are visually represented in the various views in the ORM Profiler client.
By hovering over the alert and exception icons in the Alerts column, you can quickly check which alerts / exceptions occurred by examining the tooltip. Clicking the element which has the alert assigned will show the element in the bottom pane of the client GUI where you can view the alerts in the Alerts tab.
Below you'll find a brief outline of the various alerts the analysis functions are able to find.
The Number of connections per second alert occurs if the number of connections opened per second is higher than a specified threshold.
The Number of commands executed per second alert occurs if the number of commands executed per second is higher than a specified threshold.
The Slow Transaction alert occurs if the time taken from Begin Transaction to Commit/Rollback transaction is higher than a specified threshold.
The Connection Stayed Open Too Long alert occurs if the time taken from Open connection to Close connection is higher than a specified threshold.
The Large Resultset alert is an alert which occurs when a query results in a read of more than X rows (on the datareader). X is configurable.
The Slow SQL Statement alert is an alert which occurs when a SQL statement execution takes more than X milliseconds. X is configurable.
The Slow Data Read alert is an alert which occurs when the time taken to read all rows using a datareader is more than n milliseconds. n is configurable. n is the time taken for reading the rows, not for executing the SQL statement: n starts counting as soon as the datareader is created.
Example: A SELECT statement is executed rather quickly, however due to the massive amount of data (e.g. it contains a lot of big blob/image data fields) the materialization of entity objects using the datareader takes a long time, e.g. several seconds.
The Too Many SQL Statements Per Connection alert occurs when more than n commands are executed over a single connection. n is configurable.
The Idling Connections alert occurs when a connection is open for X ms and activity over the connection (commands execution, datareader reads) are only Y ms of that X ms. The alert is raised when X-Y>=Z where Z is configurable.
Example: (LLBLGen Pro specific) Opening a connection manually (either by starting a Transaction in Selfservicing or using OpenConnection on an adapter), then doing something non-persistence wise, then executing some persistence code.
It can also be the user has written code which triggers the open / close of the connection in code high up in the call chain which keeps the connection open longer than needed.
The Massive SQL Statement alert occurs when a SQL statement is executed which is longer (in characters) than a set threshold. This alert is mainly meant to find large statements which might have been created using slow LINQ statements so the user should look into optimizing them.
The time spent in a LINQ provider isn't determinable by ORM Profiler, so in order to find the potentially slow LINQ queries, use this alert. This alert is mainly meant for Entity Framework which LINQ provider is slow when it has to produce large SQL statements.
Exceptions are not seen as an alert, but are reported separately with the element which caused the exception.
When a range is copied as a snapshot in the Real-Time Viewer, the alerts created through real-time analysis are preserved and not cleared by the analysis done on the snapshot. This is by design.
The alerts stay in the elements forever as they're present when the snapshot was created. This is to prevent accidental erasure of the alerts by re-analyzing the elements.
The real-time analysis settings are available from the Home tab and also from the real-time viewer tab. The settings are directly affecting real-time analysis in progress and are preserved to disk so next time you start the client they're loaded again. The settings work the same way as the normal analysis settings.