.Net Windows Service Business Transactions Test

By comparing the value of this measure across functions, you can identify the most popular functions. Using the detailed diagnosis of this measure, you can then figure out which specific functions are called often.

For the Summary descriptor, this measure will reveal the total number of times this function was called by the Windows service application during the last measurement period. This is a good indicator of the workload of the application.

Compare the value of this measure across functions to isolate the slowest one. 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 function calls made by this Windows service application during the last measurement period. An abnormally low value for this measure for the Summary descriptor could indicate a serious processing bottleneck.

By default, this measure will report the count of function calls 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 function calls made by the standalone service application.

To know which are the healthy function calls, use the detailed diagnosis of this measure. For the Summary descriptor, this measure will report the overall percentage of healthy function calls made by this standalone Windows service application.

By default, this measure will report the number of function calls 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 function calls means that the performance of the standalone Windows service application is deteriorating. For the Summary descriptor, this measure will report the total number of functions . This is a good indicator of the processing power of the target web site.

For the Summary descriptor, this measure will report the average response time of all the slow functions called by the target standalone Windows service application.

Use the detailed diagnosis of this measure to know which precise function calls were slow. You can drill down from a slow function to know what is causing the slowness. For the Summary descriptor, this measure will report the overall percentage of slow function calls made by the target standalone Windows service application.

A high value is a cause for concern, as function calls that throw too many errors can degrade application performance. For the Summary descriptor, this measure will report the total number of functions that encountered errors during execution. This is a good indicator of how error-prone the target service application is.

The value of this measure will help you discern if erro functions were also slow. For the Summary descriptor, this measure will report the average response time of all function calls made by the target service application.

Use the detailed diagnosis of this measure to isolate the error functions. You can even drill down from an error function in the detailed diagnosis to determine the cause of the error. For the Summary descriptor, this measure will report the overall percentage of functions executed by the target service application that is currently throwing errors.

By default, this measure will report the number of function calls 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 function calls means sub-par application performance. For the Summary descriptor, this measure will report the total number of stalled functions executed by the monitored standalone Windows service application.

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

Use the detailed diagnosis of this measure to know which precise function calls stalled. You can drill down from a stalled function call to know what is causing that function to stall. For the Summary descriptor, this measure will report the overall percentage of functions called by the target service application that is stalling.

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

If any function is executing very slowly, you may want to check the value of this measure for that function to figure out if query execution is slowing down the function. Use the detailed diagnosis of the Slow transactions measure to identify the precise slow function call. Then, drill down from that slow call 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.

A very low value is desired for this measure.

Compare the value of this measure across functions to find the error-prone function.

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

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

• Functions for which the monitored node is the entry point - these are function calls triggered by the standalone Windows services on the target node; these calls 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 function calls passing through the target node and the calls for which the target node is the entry point. This way, the All transactions measure paints the true picture of function 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 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' functions 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 load on the service.

The Avg response time measure reveals how responsive a function is from the time a function call is received and processed by the target node. This measure does not differentiate between pass-through and entry point functions, 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 performance at the business service-level. If the target node serves as a function's entry point, then this measure reports the responsiveness of that function, end-to-end - i.e., from the entry point, through all the other nodes in its path, till a response is returned to the entry point. By monitoring this measure across all nodes engaged in delivering a business service, you can identify the 'unique' functions run by the service applications on each node, measure end-to-end responsiveness of each function, and isolate the slowest function at the service-level.

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

On the other hand, if you want to determine the count of slow functions calls that are impacting the health of 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' functions are slowing down that service.

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

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

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

On the other hand, if you want to determine the count of error functions that are impacting the health of 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' functions run by the service applications on each node have encountered errors.

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

The Entry point error response time measure on the other hand, reports the average response time of 'unique' error functions 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 functions are at the service level.

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

On the other hand, if you want to determine the count of stalled function calls 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' function calls run by the service applications on each node are stalled.

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

The Entry point stalled response time measure on the other hand, reports the average responsiveness of 'unique' stalled function calls 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 function calls at the business service level.

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

For the Summary descriptor, this measure will report the average time for which all the functions executed by the target standalone Windows service application used the CPU.

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

For the Summary descriptor, this measure will report the average time for which all the functions executed by the target standalone Windows service application were blocked.

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

For the Summary descriptor, this measure will report the average time for which all the functions executed by the target service application were waiting.

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

On the other hand, if you want to determine the count of healthy functions run by a target service application for 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' functions run by the service applications on each node are.healthy.