The Top N View report shows the most problematic software services, operations, and sites on one screen. Additionally, it provides the context of the analyzer that is listed next to the software service or operation name.
With this report, you can identify the top ten operations, software services, and sites that generate the longest response time, have the largest number of affected users, and cause the largest number of errors. Each table provides the context of the analyzer.
How to Access the Report
From the CAS top menu, choose Reports ➤ RUM Analysis ➤ Top N View.
Top N By Response Time
The Top N By Response Time tables show the top ten software services, operations, and sites with the slowest response time. In the Top Operations By Response Time table, you can identify the most problematic operations. In the Top Software Services By Response Time and Top Sites By Response Time tables, you can see how many operations were completed in the slowest of the software services and sites.
Hover over the Count, Operations, and Time columns to see how many users are affected by the slow response conditions, the number of unique users, the number of application failures, the number of slow and fast operations, and server and network times.
Top N By Affected Users
The Top N By Affected Users tables show the top ten software services, operations, and sites with the largest number of affected users. In these tables, you can see the overall number of users for the worst software services, operations, and sites, as well as the number of affected users.
Hover over the Users and Affected columns to see the number of application failures, the number of slow and fast operations, and server and network times.
Top N By Error
The Top N By Error tables show the top ten software services, operations, and sites with the greatest number of errors.
The Application failures column shows the number of all transactions errors for the top ten software services, operations, and sites. The following errors are taken into account:
DNS errors
The number of DNS errors. HTTP client errors (4xx)
The sum of all HTTP client errors (4xx).
This includes 4 categories of errors (4xx), by default HTTP Unauthorized (401, 407) errors, HTTP Not Found (404) errors, custom client (4xx) errors and Other HTTP (4xx) errors. The contents of the first 3 categories can be configured by users.
However, there are two types of the 4XX errors that are of particular importance: errors 401 related to server-level authentication, and errors 404 indicating requests for non-existent content. These two error types are reported separately, by specific metrics.
• 401 Unauthorized - Server reports this error when user's credentials supplied with request do not satisfy page access restrictions. The HTTP server layer, not the application layer, reports 401 errors. The AMD will report on "Unauthorized" errors only if server-level authentication has been configured. This is common practice for sites that are comfortable with very basic user access policies. Most commercial-grade applications do not rely on server-level authentication (e.g. most of online banking applications or online shopping), but rather authenticate users on the application layer. In such a case, even if authentication fails, the server will typically send 200 OK responses and authentication error information will be explained in page content. So this kind of error is not very common in commercial sites.
• 404 Not Found - Server reports "Not Found" errors when it cannot fulfill client request for a resource. Usually it happens due to malformed URL, which directs to a non-existing page or image. Such a URL request may result from a user, who misspelled the URL, trying to access a URL that the user stored in his "Favorites" folder a long time ago, or some other mistake. Malformed URLs may also exist in invalid or incorrectly designed Web pages so the error will be reported by browsers trying to load such a page. Significant and constant number of these errors usually indicates that some pages on the server have design-related or link validation issues. In some cases, 404 errors result from the server overload. It is good practice to check whether the percentage of errors is load-related.
MQ errors
The total number of IBM WebSphere Message Queue errors, including client errors, server errors, protocol errors and security errors.
HTTP server errors (5xx)
The number of observed HTTP server errors (5xx).
The response status codes 5xx indicate cases, in which the Web server is aware that there was a server error or it is incapable of performing the request. Such error presence usually means that the Web server does not function as intended. The following 5xx errors are defined by the HTTP protocol standards:
• 500 Internal Server Error - The server encountered an unexpected condition, which prevented it from fulfilling the request.
• 501 Not Implemented - The server does not support the functionality required to fulfill the request.
• 502 Bad Gateway - The server received an invalid response from a back-end application server.
• 503 Service Unavailable - The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.
• 504 Gateway Timeout - The server did not receive response from a back-end application server.
• 505 HTTP Version Not Supported - The server does not support the HTTP protocol version that was used in the request message.
SAP GUI errors
The number of errors detected on the protocol level in communication between SAP application server and SAP GUI client as well as between SAP application server and a third party clients using Remote Function Calls (RFC).
SAP RFC errors
The number of errors detected on the protocol level in communication between a SAP application server and a SAP client plus the number of attributes which are defined as error indicators in the monitoring configuration.
SMTP errors
The total number of SMTP errors. SSL errors
The number of all SSL alerts. This metric is the sum of SSL Session Fatal Errors, SSL Handshake Errors and SSL Warnings.
Hover over the column to see the numbers of errors in each category.
The TCP Errors column shows the total number of TCP errors in the top ten software services, operations, and sites. The following TCP errors are taken into account:
TCP Errors
The total number of TCP errors.
Those errors may indicate server or application problems and therefore measurements of those are critical to understanding the issues that may affect end-user experience. AMDs measure and report on the following types of TCP errors:
• Connection Refused Errors - Client attempts to open a TCP session with a server, which rejects the request. SYN packet from Client is followed by RESET packet from Server, with matching TCP sequence numbers. This error is typically caused by resource exhaustion on the server, which is unable to accept more concurrent TCP sessions. This may be either a configuration issue (too few resources allocated in the kernel) or lack of memory. SYN flood attacks typically result in servers being unable to accept new connections.
• Server session termination error - Server is unexpectedly terminating a connection that was successfully opened. The server sends a RESET packet to the Client. Such an error originates at an application using TCP session that is monitored. It does not necessarily mean application failure; usually it means that the application encountered a condition in which it decided to immediately terminate session with the client, for example, because of an application security policy violation by the client.
• Session Abort - Client is unexpectedly terminating a connection that was successfully opened. The Client sends a RESET packet to the Server. These errors are inspected in the context of the client application and may or may not be reported. For example, the browser running HTTP may terminate the load of a GIF file if it is older than the one that it had previously cached and this is normal behavior. However, if all connections to the server are terminated because the user hits the STOP button, then this is abnormal session termination and is reported as "Aborted operation" or "Stopped Page".
• Client not responding errors (server timeout errors) - Server networking stack takes an assumption that the network connection to the client exists, but the client remains idle and does not respond. In such a case, the server closes the TCP session with the RESET packet. Such a condition may occur when the client has been silently disconnected from the network, for example, due to a link failure, or the client has crashed. Note that this error will not occur if the client has ended the session gracefully, e.g. by closing the client application.
• Server not responding errors (client timeout errors) - Client networking stack takes an assumption that network connection to the server exists, but the server remains idle and does not respond. In such a case, the client closes the TCP session with the RESET packet. This may occur either during the Session Setup phase (no response to the SYN packet), or during a normal data exchange process. Such a situation may result in the intermittent network problems between the client and the server. In the case the traffic is routed through asymmetric paths across the Internet, which is often the case, the path from the server to the client may be broken.