Measures reported by SMHttpTest
To control user accesses to a web site, web servers are configured to work with SiteMinder - a platform that authenticates, authorizes, and manages web sites. Using SiteMinder, administrators can enable Single Sign-On (SSO) for multiple web sites operating in an environment. With the SSO property of access control, a user logs in once and gains access to multiple web sites at one go, without being prompted to log into each of them separately. While SiteMinder's SSO capability saves the time and effort required to manually sign into multiple web sites, a slowdown in SiteMinder can delay/suspend accesses to all the web sites managed (i.e., protected) by it! But should SiteMinder be blamed every time a user complaints of a slowdown when accessing a protected web site? Maybe not! Given below are the steps that occur when a user tries to access a web site protected by SiteMinder:
- The user requests for a web page using HTTP/HTTPS
- The request is received by the web server and is intercepted by the SiteMinder web agent.
- The web agent determines whether or not the resource is protected. If the resource is protected, SiteMinder forces the user to login using their credentials. Typically, this is done via an HTTP POST request.
- SiteMinder authenticates the user and verifies whether or not the authenticated user is authorized for the requested web page, based on rules and policies specified in the Policy store.
- After the user is authenticated and authorized, SiteMinder grants access to the web page. Resource grant is done by providing a cookie to the client browser.
From the above figure, it is clear that a problem in any step of this multi-step user interaction can delay web site accesses! This means that a slowdown in the SiteMinder policy server can be one of the reasons for a delay in accessing a web site, but it need not be the ‘root-cause’! A processing bottleneck in the web server too can cause delays in web site accesses. Likewise, if the web agent takes too long to redirect the user's request to the login URL, the user experience with the site is bound to suffer. Similarly, if the web page requested is large and takes too long to load, access delays will become unavoidable. In such circumstances, administrators will have trouble isolating the ‘source’ of the slowdown. If the root-cause of the slowdown is not diagnosed quickly, the problem will remain unresolved for a long time, resulting in a steep fall in service levels, increase in penalties and loss of reputation.
To avoid this, administrators will have to quickly pin-point the root-cause of a slowdown and fix it; for this, they need to know how much time each step of the user interaction with a protected web site takes. The SiteMinder Web Access test does this job. The test emulates a user accessing a web site protected by SiteMinder and reports the time taken by each step of the process, so that the precise step at which the slowdown occurred can be accurately isolated and the problem promptly eliminated.
The measures made by this test are as follows:
| Measurement | Description | Measurement Unit | Interpretation |
|---|---|---|---|
| Availability | This measurement indicates whether or not this URL* was successfully accessed and valid content was returned. In other words, this measure clearly indicates whether or not step (1) to step (12) of the above figure completed successfully and the client was able to view the complete contents of the URL, till the last byte of data. *The term URL used in all discussions related to the measures of this test refers to the target URL indicated by step (1) of the above figure, unless explicitly stated otherwise. |
Percent | The value 100 for this measure indicates that the URL could be accessed successfully - i.e., the client could view the contents of the web page completely, till the last byte. The value 0 on the other hand indicates that the URL could not be accessed. This could be owing to a prolonged slowdown in the web server, performance issues with SiteMinder or an authentication failure reported by SiteMinder, processing bottlenecks experienced by the web agent, large size of the contents of the URL, etc. To zero-in on the exact reason for the inaccessibility of the configured URL, take a look at the values reported by the other measures of this test. Note that even if the URL is not protected by SiteMinder, the ‘Availability’ measure will still report the value 100, provided the user does not receive any HTML response with a response code higher than 400. In this case, you can check the value reported by the ‘URL SiteMinder protected’ measure to figure out whether the URL is protected or not. |
| Response_time | This measurement indicates the total time it took for the client to request for a URL and receive access to that URL via a session cookie. This is the sum total of the time taken to do the following:
|
Secs | Response time being high denotes a problem. Poor responsiveness can be caused due to a slowdown in the web server or SiteMinder, or because the content to be downloaded is large. Therefore, if the value of this measure is high or is increasing consistently, you will have to compare the values of the Web_resp_time, Redirect_time, SM_auth_time, and Download_time measures to figure out where the request spent maximum time; there is your bottleneck! |
| Web_availability | Indicates whether or not the web server is able to process the request for this URL and return the location of the login URL to the user. In other words, this measure indicates whether or not step (1) to step (4) of the above figure could be completed successfully. | Percent | The value 100 for this measure indicates that the web server is available, has successfully determined the protection status of the URL, and has returned the location of the login URL to the user. If the measure reports the value 0, it is indicative of the non-availability of the web server. Availability is determined based on the response code returned by the server. If the server returns a response code between 200 and 300 the very first time the configured URL is hit, it indicates that the server is available. Any response code over 400 indicates non-availability of the web server. Note that even if the URL is not protected by SiteMinder, the ‘Web_availability’ measure will still report the value 100, provided the user does not receive any HTML response with a response code higher than 400. In this case, you can check the value reported by the 'URL SiteMinder protected' measure to figure out whether the URL is protected or not. |
| Web_resp_time | Indicates the time taken to check and report whether this URL is protected or not; this is the time taken to perform steps (1), (2) and (3) of the above figure. | Secs | Response time being high denotes a problem. Poor response times may be due to the web server being overloaded or misconfigured. If the value of the Response_time measure is high, then compare the value of the Web_resp_time measure with the other response time measures reported by this test to determine whether a processing bottleneck in the web server is the reason why the client had trouble accessing the web site. |
| Redirect_time | This measure indicates the time taken by the web agent on the web server to redirect the request to the login URL (indicated by step (5) of the above figure); this is the total time taken to complete step (5) of the above figure. | Secs | Ideally, the value of this measure should be low. A high value is indicative of poor responsiveness. If the value of the Response_time measure is high, then compare the value of the Redirect_time measure with the other response time measures reported by this test to determine whether a delay in sending the location of the login URL to the client is what caused accesses to the web site to slow down. |
| SM_proctected | Indicates whether or not this URL is protected by SiteMinder; in other words, this measure checks whether the client received the login URL or not. | Boolean | While the value 1 for this measure indicates that the URL is protected by SiteMinder, the value 0 indicates that the URL is not protected. |
| SM_auth_status | Indicates whether user authentication succeeded or failed. | Percent | A value of 100% indicates that SiteMinder successfully authenticated the login credentials that were submitted to it by the web agent. The value 0 on the other hand indicates an authentication failure. If the client received an SM_SESSION cookie from the web agent, it indicates that authentication was successful. On the other hand, if the client did not receive the SM_SESSION cookie it is indicative of authentication failure. The probable cause for this failure is the submission of invalid/incorrect credentials to SiteMinder. |
| SM_auth_time | Indicates the time taken by SiteMinder to authenticate the user credentials; this is the time taken to perform steps (6), (7), (8), and (9) of the above figure. | Secs | A low value is desired for this measure. A high value is indicative of an authentication bottleneck. If the value of the Response_time measure is high, then compare the value of the SM_auth_time measure with the other response time measures reported by this test to determine whether a processing bottleneck in the SiteMinder Policy server is what is causing accesses to the web site to slow down. |
| Content_validity | This measure validates whether the content returned by this URL is valid or not. | Percent | A value of 100% indicates that the content returned by the test is valid. A value of 0% indicates that the content may not be valid. Content that matches the value of the CONTENT parameter of this test is deemed as valid content; in this case, the measure will report the value 100. If the actual content does not match the CONTENT specification, then the value of the measure will be 0. This capability for content validation is especially important for multi-tier web applications. For example, a user may not be able to login to the web site but the server may reply back with a valid HTML page where in the error message, say, “Invalid Login” is reported. In this case, the availability will be 100% (since we got a valid HTML response). If the test is configured such that the content parameter should exclude the string “Invalid Login”, in the above scenario content validity would have a value 0. |
| Response_code | Indicates the response code received by the client for the request to this URL. | Number | A value between 200 and 300 indicates a good response. A 4xx value indicates a problem with the requested content(e.g., page not found). The value 401 is indicative of an authentication issue. A 5xx value indicates a server error. |
| Content_length | The size of the content returned by the server for the request to this URL. | Kbytes | Typically the content length returned by the server for a specific URL should be the same across time. Any change in this metric may indicate the need for further investigation on the server side. |
| Download_time | Indicates the total time taken by the client to view the complete contents returned by this URL till the last byte of data; in other words, this is the time taken to complete steps (11) and (12) of the above figure. | Secs | A high value for this measure denotes that the content is taking a long time to load. This could be owing to the presence of a large number of images in the content or one/more large images. You may want to check the value of the Content_length measure to understand how large the content is. If the value of the Response_time measure is high, then compare the value of the Download_time measure with the other response time measures reported by this test to determine whether the size of the content poses a road-block to swift access to the protected web site. |