Detailed Diagnostics Revealing that Slow .Net Processing is the Reason for Transaction Slowness

Let us consider the example of a .NET application, where the following transactions are slow.

Figure 1 : Detailed diagnosis of the Slow transactions percentage measure

Let us focus on the first transaction in the slow transactions list of Figure 1. To zoom into the transaction, click on it. Figure 2 will then appear revealing the cross-application flow of that transaction.

Figure 2 : The cross-application flow of the slow transaction

This flow diagram clearly reveals the following:

  • The IIS web servers and backends through which the transaction travelled;
  • The time for which the transaction request was processed at each BTM-enabled IIS web server in the transaction path; note that this time will not be computed for IIS web servers that are in the transaction path, but are not BTM-enabled and those that are BTM-enabled but are not managed by eG Enterprise;

  • The exit calls made by each BTM-enabled node to another node as part of the transaction's journey, the time consumed by each exit call,and the number of times each type of call was made; the following exit calls are supported by eG BTM:

    • Database Query
    • HTTP
    • Web service
    • WCF

Note:

  • If a profiled node appears 'grayed out' in the cross-application transaction flow, it denotes that profiler could not collect detailed diagnostics for that node. The reasons for this could be either or both of the following:

    • Transaction responsiveness on the 'grayed out' node was either healthy or was only slightly slow, and hence, did not appear in the list of Top-N slow transactions.
    • Slow data transmission from eG agent to manager;
  • If an IIS web server makes a call to a messaging server, then. in the transaction topology, that messaging server will be identified by the URL of the exact queue/topic that is managing the request. If an IIS web server makes a SQL query call to a database server, then the details displayed for that database server in the transaction topology depends upon whether/not that database server is managed by eG Enterprise. If the database server is not managed by eG Enterprise, then such a database server will be represented in the topology using the server type (whether Oracle, Microsoft SQL etc.) and the name of the database that was accessed by the SQL query. To know the IP and port number of the unmanaged database server, you can drill-down from the Database queries call in the topology. On the other hand, if the database server in question is being monitored by eG Enterprise, then such a server will be represented in the topology using the server type, nick name, port number, and the database name. Additionally, the SID will be displayed in case of an Oracle database server, and the instance name will be displayed in case of an instance-based Microsoft SQL server.

  • Sometimes, empty nodes – i.e., nodes without any details – will be visible in the cross-application transaction flow topology. Likewise, the time spent on certain external calls may also not be displayed in the topology. This is owing to inconsistencies in the collection of detailed diagnostics.

Using conventional color codes and intuitive icons, the transaction flow chart precisely pinpoints where the transaction slowed down. In the case of above, from the color-coding it is clear that the problem is with the .Net layer of the IIS web server, Multinode3:61728. To zoom into the problem, click on that IIS web server in the transaction topology. will then appear providing a detailed Execution Analysis of the .Net methods called by Multinode3:61728.

Figure 3 : The call graph of the .Net transaction

As part of this analysis, a pie chart is presented that quickly reveals the percentage of time Multinode3:61728 in our example spent processing the server’s .Net code and making external HTTP/WCF/Web service calls. The table below the pie chart in Figure 3 lists the exact methods that performed .Net processing or made the remote calls. A quick look at this table reveals that the .Net method, ASP.destinationform_aspx:ProcessRequest invoked a series of child methods and external calls, which together took over 10000 milliseconds to execute. However, the method itself did not take any time to execute (self execution time)! Browsing the child methods called by the parent method reveals that the transaction spent over 90% of its time on the .Net call, 'DataTransferWebsite2.DestinationForm:Page_Load'. This means that the 'sun.net.www.protocol..' is the method that is delaying the transaction.

This way, eG BTM enables you to diagnose the root-cause of slowness in your .Net calls using just a few mouse clicks!

Note:

By default, the table in will not include the methods/functions within those classes that are associated with the basic .Net framework (on the target IIS web server). This is because, such functions are less likely to encounter issues. Moreover, when a transaction slows down, application experts will more often than not look for issues in the application code and not in the underlying .Net code. Also, by excluding such classes from its monitoring purview, eG Enterprise also reduces its processing overheads significantly.

If required, you can include these classes in the profiler's monitoring scope or can even exclude more classes from monitoring. For this, do the following:

  1. Edit the eG_DotNetBTM.ini in the <EG_INSTALL_DIR>\manager\config directory on the eG manager host.

  2. In the [EXCLUDE] section of the file, you will find a CLASSES parameter. By default, this parameter will be set to a semicolon-separated list of (.Net framework) class patterns to be excluded from monitoring. The default specification will be as follows:

    [EXCLUDE]

    CLASSES=System.*;Microsoft.*;AsyncInvocationWithFilters.*;

  3. If you want the profiler to monitor any of the excluded files, then simply remove the corresponding file pattern from the semicolon-separated list. For instance, if you want the profiler to monitor all classes that begin with System., then remove the System.* pattern from the CLASSES listed under [EXCLUDE]. If this is done, then the specification will be as shown below:

     

    [EXCLUDE]

    CLASSES=Microsoft.*;AsyncInvocationWithFilters.*;

  4. Likewise, if only a sub-set of the excluded class patterns are to be included in the profiler's monitoring scope, then use the CLASSES parameter in the [INCLUDE] section of the file. For instance, of all classes of the System.* pattern, if you want only the System.Security classes to be monitored, then, your specification in the [INCLUDE] section will be as follows:

    [INCLUDE]

    CLASSES=Microsoft.CRM.*;System.Security.*;

  5. Additional class patterns or classes can be appended to the CLASSES list under [INCLUDE] by separating each class pattern/class name by a semi-colon.
  6. Finally, save the file.