.NET Core Business Transactions Test

The responsiveness of a transaction is the key determinant of user experience with that transaction; if response time increases, user experience deteriorates. To make users happy, a business transaction should be rapidly processed by each of the IIS/Kestrel web servers in its path. Processing bottlenecks on a single server can slowdown/stall an entire business transaction or can cause serious transaction errors. This in turn can badly scar the experience of users. To avoid this, administrators should promptly identify slow/stalled/errored transactions, isolate the web server on which the slowness/error occurred, and uncover what caused the aberration on that server – is it owing to SQL queries executed by the server? Or is it because of external calls – eg., HTTP calls, web service calls, etc. - made by that node? The .NET Core Business Transactions test helps with this!

This test runs on a BTM-enabled Kestrel/IIS web servers in an IT infrastructure and tracks all the transaction requests received by any web site that has been configured for monitoring on that server. The test then groups requests based on user-configured pattern specifications. For each transaction pattern, the test then computes and reports the average time taken by that server to respond to the transaction requests of that pattern to the configured web site. In the process, the test identifies the slow/stalled transactions of that pattern, and reports the count of such transactions and their responsiveness. Detailed diagnostics provided by the test accurately pinpoint the exact transaction URLs that are slow/stalled, the total round-trip time of each transaction, and also indicate when such transaction requests were received by that server. The slowest transaction in the group can thus be identified.

Moreover, to enable administrators to figure out if the slowness can be attributed to a bottleneck in SQL query processing, the test also reports the average time the transactions of each pattern took to execute SQL queries. If a majority of the queries are slow, then the test will instantly capture the same and notify administrators.

Additionally, the test promptly alerts administrators to error transactions of each pattern. To know which are the error transactions, the detailed diagnosis capability of the test can be used.

This way, the test effortlessly measures the performance of each transaction to a web site on a Kestrel/IIS web server, highlights transactions that are under-performing, and takes administrators close to the root-cause of poor transaction performance.

Note:

This test will report metrics only if the following pre-requisites are fulfilled:

  • The eG .NET Core Profiler should be installed and configured on the target web server.
  • If the .NET Core web site/application being monitored is running on an IIS web server, then the IIS Management Scripts and Tools feature should be installed and enabled on that server.

Target of the Test : A BTM-enabled Kestrel/IIS web server, or a reverse proxy Apache web server running on the same machine as that of a BTM-enabled Kestrel web server

Agent deploying the test : An internal agent

Output of the test : One set of results for each grouped URL

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed

Host

The host for which the test is to be configured.

Port

The port number through which the Apache Hive communicates. The default port is 80.

Healthy URL Trace

By default, this flag is set to No. This means that eG Enterprise will not collect detailed diagnostics for those transactions that are healthy. If you want to enable the detailed diagnosis capability for healthy transactions as well, then set this flag to Yes.

Max Healthy URLs per Test Period

This parameter is applicable only if the Healthy URL Trace flag is set to ‘Yes’. Here, specify the number of top-n transactions that should be listed in the detailed diagnosis of the Healthy transactions measure, every time the test runs. By default, this is set to 50, indicating that the detailed diagnosis of the Healthy transactions measure will by default list the top-50 transactions, arranged in the descending order of their response times.

Max Slow URLs per Test
Period

Specify the number of top-n transactions that should be listed in the detailed diagnosis of the Slow transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Slow transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.

Max Stalled URLs per Test Period

Specify the number of top-n transactions that should be listed in the detailed diagnosis of the Stalled transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Stalled transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.

Max Error URLs per Test
Period

Specify the number of top-n transactions that should be listed in the detailed diagnosis of the Error transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Error transactions measure will by default list the top-10 transactions, in terms of the number of errors they encountered.

Method Execution Cutoff (MS)

From the detailed diagnosis of slow/stalled/error transactions, you can drill down and perform deep execution analysis of a particular transaction. In this drill-down, the methods invoked by that slow/stalled/error transaction are listed in the order in which the transaction calls the methods. By configuring a method execution cutoff, you can make sure that methods that have been executing for a duration greater the specified cutoff are alone listed when performing execution analysis. For instance, if you specify 5 here, then the Execution Analysis window for a slow/stalled/error transaction will list only those methods that have been executing for over 5 milliseconds. This way, you get to focus on only those methods that could have caused the slowness, without being distracted by inconsequential methods. By default, the value of this parameter is set to 250 ms.

SQL Execution Cutoff (MS)

Typically, from the detailed diagnosis of a slow/stalled/error transaction to a web site, you can drill down to view the SQL queries (if any) executed by that transaction from that node and the execution time of each query. By configuring a SQL Execution Cutoff, you can make sure that queries that have been executing for a duration greater the specified cutoff are alone listed when performing query analysis. For instance, if you specify 5 here, then for a slow/stalled/error transaction, the SQL Queries window will display only those queries that have been executing for over 5 milliseconds. This way, you get to focus on only those queries that could have contributed to the slowness. By default, the value of this parameter is set to 10 ms.

Max Grouped URLs per Measure Period

This test groups URLs according to the 'URL Segments' specification. These grouped URLs will be the descriptors of the test. For each grouped URL, response time metrics will be aggregated across all transaction URLs in that group and reported.

When monitoring web sites/web applications to which the transaction volume is normally high, this test may report metrics for hundreds of descriptors. If all these descriptors are listed in the Layers tab page of the eG monitoring console, it will certainly clutter the display. To avoid this, by default, the test displays metrics for a maximum of 50 descriptors – i.e., 50 grouped URLs alone – in the eG monitoring console, during every measure period. This is why, the Max Grouped URLs per Measure Period parameter is set to 50 by default.

To determine which 50 grouped URLs should be displayed in the eG monitoring console, the eG BTM follows the below-mentioned logic:

  • Top priority is reserved for URL groups with error transactions. This means that eG BTM first scans URL groups for error transactions. If error transactions are found in 50 URL groups, then eG BTM computes the aggregated response time of each of the 50 groups, sorts the error groups in the descending order of their response time, and displays all these 50 groups alone as the descriptors of this test, in the sorted order.
  • On the other hand, if error transactions are found in only one / a few URL groups – say, only 20 URL groups – then, eG BTM will first arrange these 20 grouped URLs in the descending order of their response time. It will then compute the aggregated response time of the transactions in each of the other groups (i.e., the error-free groups) that were auto-discovered during the same measure period. These other groups are then arranged in the descending order of the aggregated response time of their transactions. Once this is done, eG BTM will then pick the top-30 grouped URLs from this sorted list.
  • In this case, when displaying the descriptors of this test in the Layers tab page, the 20 error groups are first displayed (in the descending order of their response time), followed by the 30 ‘error-free’ groups (also in the descending order of their response time).

At any given point in time, you can increase/decrease the maximum number of descriptors this test should support by modifying the value of the Max Grouped URSs Per Measure Period parameter.

Max SQL Queries Per Transaction

Typically, from the detailed diagnosis of a slow/stalled/error transaction to a web site, you can drill down to view the SQL queries (if any) executed by that transaction from that node and the execution time of each query. By default, eG picks the first 500 SQL queries executed by the transaction, compares the execution time of each query with the SQL Execution Cutoff configured for this test, and displays only those queries with an execution time that is higher than the configured cutoff. This is why, the 'Max SQL Queries Per Transaction' parameter is set to 500 by default.

To improve agent performance, you may want the SQL Execution Cutoff to be compared with the execution time of a less number of queries – say, 200 queries. Similary, to increase the probability of capturing more number of long-running queries, you may want the SQL Execution Cutoff to be compared with the execution time of a large number of queries – say, 1000 queries. For this, you just need to modify the 'Max SQL Queries Per Transaction' specification to suit your purpose.

Filtered URL Patterns

By default, this test does not track requests to the following URL patterns:

*.ttf, *.otf, *.woff, *.woff2, *.eot, *.cff, *.afm, *.lwfn, *.ffil, *.fon, *.pfm, *.pfb, *.std, *.pro, *.xsf, *.jpg, *.jpeg, *.jpe, *.jif, *.jfif, *.jfi, *.jp2, *.j2k, *.jpf, *.jpx, *.jpm, *.jxr, *.hdp, *.wdp, *.mj2, *.webp, *.gif, *.png, *.apng, *.mng, *.tiff, *.tif, *.xbm, *.bmp, *.dib, *.svg, *.svgz, *.mpg, *.mpeg, *.mpeg2, *.avi, *.wmv, *.mov, *.rm, *.ram, *.swf, *.flv, *.ogg, *.webm, *.mp4, *.ts, *.mid, *.midi, *.rm, *.ram, *.wma, *.aac, *.wav, *.ogg, *.mp3, *.mp4, *.css, *.js, *.ico|/egurkha*

If required, you can remove one/more patterns from this default list, so that such patterns are monitored, or can append more patterns to this list in order to exclude them from monitoring.

Show Cookies

An HTTP cookie is a small piece of data sent from a website and stored on the user's computer by the user's web browser while the user is browsing. Most commonly, cookies are used to provide a way for users to record items they want to purchase as they navigate throughout a website (a virtual "shopping cart" or "shopping basket"). To keep track of which user is assigned to which shopping cart, the server sends a cookie to the client that contains a unique session identifier (typically, a long string of random letters and numbers). Because cookies are sent to the server with every request the client makes, that session identifier will be sent back to the server every time the user visits a new page on the website, which lets the server know which shopping cart to display to the user. Another popular use of cookies is for logging into websites. When the user visits a website's login page, the web server typically sends the client a cookie containing a unique session identifier. When the user successfully logs in, the server remembers that that particular session identifier has been authenticated, and grants the user access to its services. If you want to view and analyze the useful information that is stored in such HTTP response cookies that a web server sends, then set this flag to Yes. By default, this flag is set to No, indicating that cookie information is not reported by default as part of detailed diagnostics.

Show Headers

HTTP headers allow the client and the server to pass additional information with the request or the response. A request header is a header that contains more information about the resource to be fetched or about the client itself. If you want the additional information stored in a request header to be displayed as part of detailed diagnostics, then set this flag to Yes. By default, this flag is set to No indicating that request headers are not displayed by default in the detailed diagnosis.

URL Segments

This test groups transaction URLs based on the URL segments count configured for monitoring and reports aggregated response time metrics for every group. Using this parameter, you can specify the number of URL segments based on which the transactions are to be grouped.

URL segments are the parts of a URL (after the base URL) or path delimited by slashes. So if you had the URL: http://www.eazykart.com/web/shopping/sportsgear/login.jsp, then http://www.eazykart.com will be the base URL or domain, /web will be the first URL segment, /shopping will be the second URL segment, and /sportsgear will be the third URL segment, and /login.jsp will be the fourth URL segment. By default, this parameter is set to 3. This default setting, when applied to the sample URL provided above, implies that the eG agent will aggregate response time metrics to all transaction URLs under /web/shopping/sportsgear. Note that the base URL or domain will not be considered when counting URL segments. This in turn means that, if a web site receives transaction requests for the URLs such as http://www.eazykart.com/web/shopping/sportsgear/login.jsp, http://www.eazykart.com/web/shopping/sportsgear/jerseys.jsp, http://www.eazykart.com/web/shopping/sportsgear/shoes.jsp, http://www.eazykart.com/web/shopping/sportsgear/gloves.jsp, etc., then the eG agent will track the requests and responses for all these URLs, aggregate the results, and present the aggregated metrics for the descriptor /web/shopping/sportsgear. This way, the test will create different transaction groups based on each of the third-level URL segments – eg. /web/shopping/weddings, /web/shopping/holiday, /web/shopping/gifts etc. – and will report aggregated metrics for each group so created.

If you want, you can override the default setting by providing a different URL segment number here. For instance, your specification can be just 2. In this case, for the URLtp://www.eazykart.com/web/shopping/login.jsp, the test will report metrics for the descriptor web/shopping.

Mask SQL

If eG BTM finds that one/more slow database queries are responsible for the slowness that users are experiencing with a transaction, then you can drill-down from the cross-application transaction topology of that transaction to view the slow SQL queries run by that transaction. This way, you can accurately isolate the root-cause of the slowness. By default, if any of these queries include confidential information such as passwords, then eG Enterprise will mask the passwords in the query using the '?' (question mark) character. This way, eG Enterprise protects your business-critical data from abuse by intruders. Accordingly, this flag is set to Yes by default. For security reasons, we recommend that you do not change the default status of this flag. However, for some reason, if you want the password to be visible in clear text in the SQL queries displayed as part of the detailed analytics, then you can unmask the password by setting this flag to No.

Mask Public IP, Mask Private IP

The detailed diagnosis of this test lists the URLs of the problematic transactions to the target web site/application. Alongside the URLs, the IP address of the client from which each transaction was initiated is also displayed. By default, this client IP address - whether it is a public IP or a private IP - is masked by replacing the last octet with an 'x' - i.e., the IP address 192.168.10.90 will by default be displayed as 192.168.10.x in the detailed diagnosis. This is done to secure the target web site/application from malicious attacks. This is why, the Mask Public IP and Mask Private IP flags are set to Yes by default. For security reasons, we recommend that you do not change the default status of these flags.However, for some reason, if you want the full client IP address to be displayed in detailed diagnosis, then you can set both the flags to No.

Mask URL Params

The detailed diagnosis of this test lists the URLs of the problematic transactions to the target web site/application, so that administrators can accurately identify which specific transactions are adversely impacting user experience with the target web site/application. The URLs so displayed may sometimes include parameters/arguments that may be required by the corresponding transaction to execute. Sometimes, these parameters could carry sensitive information such as passwords. If any URL takes a password as a parameter/argument, then by default, this password is masked in the detailed diagnosis using the '?' (question mark) character. This is done to secure the target web site/application from malicious attacks. This is why, the Mask URL Params flag is set to Yes by default. For security reasons, we recommend that you do not change the default status of these flags. However, for some reason, if you want the password to be visible in clear text in the URLs in detailed diagnosis, then you can unmask the password by setting this flag to No.

Virtual Kestrel Port

This parameter is available only when configuring the .NET Core Business Transactions test for an Apache web server that is setup as a reverse proxy for a Kestrel web server running on the same machine.

Specify the port number at which the target web site/application listens.

DD Frequency

Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measures reported by the test
Measurement Description Measurement Unit Interpretation

All transactions

Indicates the total number of requests received for transactions of this pattern during the last measurement period.

Number

By comparing the value of this measure across transaction patterns, you can identify the most popular transaction patterns. Using the detailed diagnosis of this measure, you can then figure out which specific transactions of that pattern are most requested.

For the Summary descriptor, this measure will reveal the total number of transaction requests received by the target web site during the last measurement period. This is a good indicator of the transaction workload on that web site.

Avg response time

Indicates the average time taken by the transactions of this pattern to complete execution.

Milliseconds

Compare the value of this measure across patterns to isolate the type of transactions that were taking too long to execute. You can then use the detailed diagnosis of the All transactions measure of that group to know how much time each transaction in that group took to execute. This will lead you to the slowest transaction.

For the Summary descriptor, this measure will reveal the average responsiveness of all the transaction requests received by the target web site during the last measurement period. An abnormally low value for this measure for the Summary descriptor could indicate a serious processing bottleneck on the target web site.

Healthy transactions

 

 

Number

By default, this measure will report the count of transactions with a response time less than 4000 milliseconds. You can change this default setting by modifying the thresholds of the Avg response time measure using the eG admin interface.

For the Summary descriptor, this measure will report the total number of healthy transactions on the target web site.

Healthy transactions percentage

Indicates what percentage of the total number of transactions of this pattern is healthy.

Percent

To know which are the healthy transactions, use the detailed diagnosis of this measure. For the Summary descriptor, this measure will report the overall percentage of healthy transactions on the target web site.

Slow transactions

Indicates the number of transactions of this pattern that were slow during the last measurement period.

Number

By default, this measure will report the number of transactions with a response time higher than 4000 milliseconds and lesser than 60000 milliseconds. You can change this default setting by modifying the thresholds of the Avg response time measure using the eG admin interface.

A high value for this measure is a cause for concern, as too many slow transactions means that user experience with the web application is poor. For the Summary descriptor, this measure will report the total number of slow transactons on the target web site. This is a good indicator of the processing power of the target web site.

Slow transaction response time

Indicates the average time taken by the slow transactions of this pattern to execute.

Milliseconds

For the Summary descriptor, this measure will report the average response time of all the slow transactions on the target web site.

Slow transactions percentage

Indicates what percentage of the total number of transactions of this pattern is currently slow.

Percent

Use the detailed diagnosis of this measure to know which precise transactions of a pattern are slow. You can drill down from a slow transaction to know what is causing the slowness. For the Summary descriptor, this measure will report the overall percentage of slow transactions on the monitored web site.

Error transactions

Indicates the number of transactions of this pattern that experienced errors during the last measurement period.

Number

A high value is a cause for concern, as too many error transactions to a web application can significantly damage the user experience with that application. For the Summary descriptor, this measure will report the total number of error transactons on the target web site. This is a good indicator of how error-prone the target web site is.

Error transactions response time

Indicates the average duration for which the transactions of this pattern were processed before an error condition was detected.

Milliseconds

The value of this measure will help you discern if error transactions were also slow. For the Summary descriptor, this measure will report the average response time of all error transactions on the target web site.

Error transactions percentage

Indicates what percentage of the total number of transactions of this pattern is experiencing errors.

Percent

Use the detailed diagnosis of this measure to isolate the error transactions. You can even drill down from an error transaction in the detailed diagnosis to determine the cause of the error. For the Summary descriptor, this measure will report the overall percentage of transactions of this pattern on the target web site that is currently experiencing errors.

Stalled transactions

Indicates the number of transactions of this pattern that were stalled during the last measurement period.

Number

By default, this measure will report the number of transactions with a response time higher than 60000 milliseconds. You can change this default setting by modifying the thresholds of the Avg response time measure using the eG admin interface.

A high value is a cause for concern, as too many stalled transactions means that user experience with the web application is poor. For the Summary descriptor, this measure will report the total number of stalled transactons on the target web site.

Stalled transactions response time:

Indicates the average time taken by the stalled transactions of this pattern to execute.

Milliseconds

For the Summary descriptor, this measure will report the average response time of all stalled transactions on the target web site.

Stalled transactions percentage

Indicates what percentage of the total number of transactions of this pattern is stalling.

Percent

Use the detailed diagnosis of this measure to know which precise transactions of a pattern are stalled. You can drill down from a stalled transaction to know what is causing that transaction to stall. For the Summary descriptor, this measure will report the overall percentage of transactions of this pattern on the target web site that is stalling.

Slow SQL statements executed

Indicates the number of slow SQL queries that were executed by the transactions of this pattern during the last measurement period.

Number

For the Summary descriptor, this measure will report the total number of slow SQL queries executed by all transactions to the target web site.

Avg slow SQL statement time

Indicates the average execution time of the slow SQL queries that were run by the transactions of this pattern.

Milliseconds

If there are too many slow transactions of a pattern, you may want to check the value of this measure for that pattern to figure out if query execution is slowing down the transactions. Use the detailed diagnosis of the Slow transactions measure to identify the precise slow transaction. Then, drill down from that slow transaction to confirm whether/not database queries have contributed to the slowness. Deep-diving into the queries will reveal the slowest queries and their impact on the execution time of the transaction.

Total transactions per minute

Indicates the number of transactions of this pattern that are executed per minute.

Number

 

Error transactions per minute

Indicates the number of error transactions of this pattern that are executed per minute.

Number

A very low value is desired for this measure.

Compare the value of this measure across transaction patterns to find that pattern of transactions that is experiencing errors frequently.

Entry point request count

Indicates the total number of requests of this pattern for which the monitored node was the entry point.

Number

Any web / web application server node typically processes two types of transaction requests. They are:

  • Requests passing through the monitored node - these are requests that will also be processed by nodes before and after the target node in the transaction topology;

  • Requests for which the monitored node is the entry point - these are requests that are routed directly from the user to the target node; these requests may be processed by other nodes after the target node in the transaction topology, but will not have any predecessors.

The All transactions measure reports the sum of the requests passing through the target node and the requests for which the target node is the entry point. This way, the All transactions measure paints the true picture of transaction load on a specific node.

Service managers/owners on the other hand, will be less interested in measuring load at the node-level; instead, they will be keen to determine transaction load at the business service-level. This is where the Entry point request count helps! For a specific node, this measure reports the count of 'unique' transactions (of a given pattern) for which that node is the entry point. By monitoring this count across all nodes that are engaged in delivering a business service, service managers can accurately ascertain the total transaction load on the service.

Entry point avg response time

Indicates the average time taken by the transactions (of this pattern) for which the target node is the entry point, to complete execution.

Milliseconds

The Avg response time measure reveals how responsive a transaction pattern is from the time requests of that pattern are received by the target node. This measure does not differentiate between pass-through transactions and entry point transactions, and is hence a good indicator of the workload processing ability of the target node.

The Entry point avg response time measure on the other hand, enables service owners/managers to accurately measure transaction performance at the business service-level. If the target node serves as a transaction's entry point, then this measure reports the responsiveness of that transaction, end-to-end - i.e., from the entry point, through all the other nodes in its path, till the user receives the responses back. By monitoring this measure across all nodes engaged in delivering a business service, you can identify the 'unique' transactions to the service as a whole, measure end-to-end responsiveness of each transaction, and isolate the slowest transaction at the service-level.

Entry point slow request count

Indicates the number of slow transactions( of this pattern) for which the target node is the entry point.

Number

The Slow transactions measure captures the total count of transactions that have been observed to be slow, from the time the transaction requests reach the target node, till responses are returned to the target node. Since this measure does not differentiate between entry point transactions and pass through transactions, you can use this measure to accurately determine the total number of transactions to a 'target' node that slowed down.

On the other hand, if you want to determine the count of slow transactions to a 'business service', you can use the Entry point slow request count measure. With the help of the values reported by this measure for every node that supports a business service, you can ascertain how many 'distinct' transactions to that service are slow.

Entry point slow response time

Indicates the average execution time of the slow transactions (of this pattern) for which the target node is the entry point,

Milliseconds

The Slow transaction response time measure reports the time that elapsed from when the target node received slow transaction requests till when it responded to the requests. Since this measure does not differentiate between pass-through and entry point requests, it will give you a fair idea of overall transaction slowness on the 'target node'.

The Entry point slow response time measure on the other hand, captures slowness by observing transaction response time from its entry point. Using the values reported by this measure for every node that supports a business service, you can monitor transaction slowness at the business service-level.

Entry point error request count

Indicates the count of error transactions (of this pattern) for which the target node is the entry point.

Number

The Error transactions measure captures the total count of transactions that have encountered errors, from the time the transaction requests reach the target node, till responses are returned to the target node. Since this measure does not differentiate between entry point transactions and pass through transactions, you can use this measure to accurately determine the total number of error transactions to a 'target' node.

On the other hand, if you want to determine the count of error transactions to a 'business service', you can use the Entry point error request count measure. With the help of the values reported by this measure for every node that supports a business service, you can ascertain how many 'distinct' transactions to that service have encountered errors.

Entry point error response time

Indicates the average execution time of the error transactions (of this pattern) for which the target node is the entry point,

Milliseconds

The Error transaction response time measure reports the time that elapsed from when the target node received error transaction requests till when responses were returned to that node. Since this measure does not differentiate between pass-through and entry point requests, it will give you a fair idea of the overall responsiveness of error transactions on the 'target node'.

The Entry point error response time measure on the other hand, reports the average response time of 'unique' error transactions from their entry point. Using the values reported by this measure for every node that supports a business service, you can understand how responsive error transactions to a 'business service' are.

Entry point stalled request count

Indicates the number of stalled transactions (of this pattern) for which the target node is the entry point.

Number

The Stalled transactions measure captures the total count of transactions that have been observed to be stalling, from the time the transaction requests reached the target node, till responses are returned to the target node. Since this measure does not differentiate between entry point transactions and pass through transactions, you can use this measure to accurately determine the total number of transactions to a 'target' node that have stalled.

On the other hand, if you want to determine the count of stalled transactions to a 'business service', you can use the Entry point stalled request count measure. With the help of the values reported by this measure for every node that supports a business service, you can ascertain how many 'distinct' transactions to that service are stalled.

Entry point stalled response time

Indicates the average execution time of the stalled transactions (of this pattern) for which the target node is the entry point,

Milliseconds

The Stalled transaction response time measure reports the time that elapsed from when the target node received stalled transaction requests till when it received responses to those requests. Since this measure does not differentiate between pass-through and entry point requests, it is a good measure of the overall responsiveness of stalled transactions to the 'target node'.

The Entry point stalled response time measure on the other hand, reports the average responsiveness of 'unique' stalled transactions from their entry point. Using the values reported by this measure for every node that supports a business service, you can gauge the responsiveness of stalled transactions to a business service.

Avg CPU time

Indicates the average time for which transactions of this pattern were utilizing the CPU.

Msecs

Compare the value of this measure across transaction patterns to accurately identify the CPU-intensive transaction patterns.

For the Summary descriptor, this measure will report the average time for which all the transactions on the target node used the CPU.

Avg block time

Indicates the average duration for which transactions of this pattern were blocked and could not execute.

Milliseconds

If the Avg response time for any transaction pattern is very high, you may want to check the value of this measure for that pattern. This will help you figure out whether/not prolonged blocking is causing transactions of that pattern to slow down or stall.

For the Summary descriptor, this measure will report the average time for which all the transactions on the target node were blocked.

Avg wait time

Indicates the average duration for which transactions of this pattern were waiting before they resumed execution.

Milliseconds

If the Avg response time for any transaction pattern is very high, you may want to check the value of this measure for that pattern. This will help you figure out whether/not a very high waiting time is what is causing the transactions to slow down/stall.

For the Summary descriptor, this measure will report the average time for which all the transactions on the target node were waiting.

Entry point healthy request count

Indicates the number of healthy transactions (of this pattern) for which the target node is the entry point.

Number

The Healthy transactions measure captures the total count of transactions that have been observed to be healthy, from the time the transaction requests reach the target node, till responses are returned to the target node. Since this measure does not differentiate between entry point transactions and pass through transactions, you can use this measure to accurately determine the total number of healthy transactions to a 'target' node.

On the other hand, if you want to determine the count of healthy transactions to a 'business service', you can use the Entry point healthy request count measure. With the help of the values reported by this measure for every node that supports a business service, you can ascertain how many 'distinct' transactions to that service are healthy.

Entry point total calls per minute

Indicates the total number of transaction calls (of this pattern) that were received per minute by the entry point.

Number

 

Entry point error transactions per minute

Indicates the number of error transaction calls (of this pattern) that were received per minute by the entry point.

Number

 

Satisfaction score

Indicates the Apdex score / Satisfaction score of the transactions of this pattern.

Number

Apdex (Application Performance Index) is an open standard developed by an alliance of companies. It defines a standard method for reporting and comparing the performance of software applications in computing. Its purpose is to convert measurements into insights about user satisfaction, by specifying a uniform way to analyze and report on the degree to which measured performance meets user expectations.

The Apdex method converts many measurements into one number on a uniform scale of 0-to-1 (0 = no users satisfied, 1 = all users satisfied). The resulting Apdex score is a numerical measure of user satisfaction with the performance of enterprise applications. This metric can be used to report on any source of end-user performance measurements for which a performance objective has been defined.

The Apdex formula is:

Apdext = (Satisfied Count + Tolerating Count / 2) / Total Samples

This is nothing but the number of satisfied samples plus half of the tolerating samples plus none of the frustrated samples, divided by all the samples.

A score of 1.0 means all responses were satisfactory. A score of 0.0 means none of the responses were satisfactory. Tolerating responses half satisfy a user. For example, if all responses are tolerating, then the Apdex score would be 0.50.

Ideally therefore, the value of this measure should be 1.0. A value less than 1.0 indicates that the user experience with the transactions has been less than satisfactory.