Monitoring Web Applications with Application Response

Transcription

1 Monitoring Web Applications with Application Response For time-critical Web-based applications, even a short-term performance problem can cause lost revenue when customers cannot place orders or they become frustrated with slow response. ehealth Application Response provides the tools and information needed to monitor and manage the response time of Web applications, anticipate and troubleshoot performance problems, and plan for growth. Benefits ehealth Application Response can help you to manage the performance of Web applications by monitoring end-user response times. Live Health can trigger alarms that alert you to response time problems for Web services, and the drill-down capabilities of ehealth reports enable you to identify the scope and source of performance problems. Use Application Response and other ehealth components to achieve the following benefits: 1. Avoid lost revenue and maintain customer satisfaction by ensuring acceptable performance levels for Web applications. Set response time thresholds that will generate alarms when performance begins to degrade, allowing problems to be fixed before response times degrade to unacceptable levels. 2. Accelerate diagnosis of Web performance problems by determining which business services are affected and isolating response problems to the client, the network, or the server. 3. Monitor response times for both high-speed access users and dial-up users to ensure that each group experiences acceptable levels of service. 4. When making infrastructure changes, monitor Web performance to determine the impact of the change on response time. 5. Quickly compare current versus historical performance to answer user questions about perceived slowness in their Web response times. 6. Measure the impact of degradations in Web performance caused by viruses, worms, and local power outages. 7. Improve capacity planning by watching trends on activity levels and response times for Web services. As Web usage increases, predict when you will need to add equipment to maintain desired response times. Fix Performance Problems before Users Notice. Avoid lost revenues and dissatisfied customers by ensuring acceptable service levels for your businesscritical Web applications, such as order entry, customer service, securities trading, and real-time production control. Use Application Response with Live Health to set thresholds that trigger alarms when performance approaches unacceptable levels. Live Health can automatically notify IT personnel when performance begins to degrade, so they have time to identify and fix problems before response times degrade to the point where users notice the delays and become impatient. Accelerate Diagnosis of Performance Problems. When Application Response identifies a problem with a Web service, you can easily determine whether the slowdown is due to the client, the network, or the server. This information allows you to direct the efforts of your IT staff to the appropriate area quickly. In addition, Application Response can identify whether a problem is restricted to a particular user, group, or location. Drill-down reports provide additional troubleshooting details to investigate the source of the problem. With this information easily available, IT staff can improve the mean time to repair (MTTR) and keep your Web users productive and customers satisfied with minimal disruption. Monitor Response Times for High-Speed Access and Dial-Up Users. To avoid losing impatient customers, the load time for a Web page must be fast. With Application Response, you can monitor actual load times experienced by high-speed access users and dial-up users. This information can help you tune your Web page design to provide faster load times. For dial-up users with slow connections such as field employees and customers using older technologies, these optimizations can improve productivity and prevent frustration.

2 2 Monitoring Web Applications with Application Response Monitor Web Performance When Making Infrastructure Changes. When making changes to the infrastructure of a Web application, you need to ensure that the changes do not negatively impact users, degrading response time. Use Application Response to compare current performance with past performance to determine how such changes affect response times for your Web applications. For example, if you upgrade the Web application or browser software, you can use Application Response to determine how much the change has improved or degraded response time for Web users. You can also monitor performance changes after upgrading the firewall or operating system on your Web server or making other changes to the infrastructure. Compare Current versus Historical Performance. Application Response records Web response times for actual end-user activity to provide insight to the user experience. You no longer need to rely on anecdotal feedback or perceptions from users who complain that the Internet is too slow or that performance seems worse today than last week. You can organize the data and reports by user group, location, and transaction type to compare the performance over a time range and for similar users or Web applications. With this data easily available, you can make decisions and address performance questions based on data, not guesses or personal impressions. Measure the Impact of Degradations in Web Performance. When a worm begins to clog the Internet with excessive traffic or a local power outage forces Internet traffic to be rerouted to alternate servers, the resulting slowdowns can have a direct impact on your bottom line. Use Application Response to determine the impact of these Internet events on your business by identifying which Web services, regional customers, or business locations are affected, and to what extent. Improve Capacity Planning. Application Response allows you to monitor the relationship between the activity level of a Web service and average response time. As the number of users increases and the activity level rises, you can check whether response time is also beginning to increase. By watching these trends, you can predict when you will need to add another Web server or increase network bandwidth to accommodate new users. Application Response provides the data you need to justify capital expenditures and plan for growth. Monitoring Web Services Application Response can monitor diverse types of Web services, including commercial and custom Web applications, intranets, extranets, and Web portals. It can monitor all Web activity to provide a general understanding of average response time, or monitor specific Web services, transactions, and related servers and ports. For example, a major financial institution relies on the Internet as a primary communications medium to provide service to consumers, branch offices, and corporate customers. It can use Application Response to monitor Web-based activity in the following ways. Web Applications. The organization s online banking system is a Web application. Consumers expect consistent, reliable response time when conducting online banking. Unreliable access to their accounts degrades their confidence in the system, which may, in turn, encourage them to take their business to a competitor. Application Response can monitor response time from different locations, measuring the quality of service being delivered and watching for performance problems. Intranets. The organization maintains an intranet where employees can access the latest internal corporate information. Application Response can monitor the time required for employees to access the intranet, ensuring that they can quickly obtain the information they need. Extranets or Web Portals. Suppliers, vendors, and partners may need direct access to a corporate extranet or Web portal to exchange large volumes of data, collaborate on joint projects, and share news of common interest. Application Response can monitor how long it takes the organization s partners to access the extranet to ensure that business proceeds on schedule.

3 3 Value 1: Fix Performance Problems before Users Notice To maintain customer satisfaction with your Web services, set up Application Response to monitor end-user response times and use Live Health to define performance thresholds for monitored transactions. As Web performance begins to degrade, Live Health can raise escalating alarms, giving you time to investigate and correct the problem before users notice significant delays. A Case Study: Web-Based Customer Service. Customer service representatives at Tuvw.com use a Web-based customer service application to respond to customer questions, log and track problems, and record solutions. They use Application Response to monitor four important transactions for the application: access (retrieve a customer record), credit check, delete, and search. Fast response time with the customer service application allows representatives to serve more customers each day. Slow response time results in impatient customers, lower resolution rates, and reduced productivity of representatives. Receive Alarms Triggered by Thresholds. To ensure fast response time for customer service representatives, the IT staff at Tuvw.com uses Live Health to define a series of thresholds for Web transactions that escalate the problem as performance continues to degrade, as follows: Warning when response time exceeds 2 seconds Minor alarm when response time exceeds 3 seconds Major alarm when response time exceeds 4 seconds Critical alarm when response time exceeds 5 seconds When Web performance approaches or exceeds a threshold, Live Health simultaneously displays these alarms in the Live Exceptions browser, a Live Status diagram, and an or pager message that is automatically sent to on-call IT personnel. These escalating alarms give the IT staff the time they need to recognize, troubleshoot, and repair the problem before representatives notice significant delays. For example, the following is a sample that Live Health sends when response time is approaching a threshold. The indicates the client system, Web application, transaction, and Web server involved. This information allows IT staff at Tuvw.com to quickly identify the problem area, so they can further investigate and take appropriate action. From: NetHealth User [mailto:george@company.com] Sent: Thursday, December 04, :28 AM To: custserviceadmin@tuvw.com Subject: Alarm major Response Time approaching threshold; service alert orden-pc-custservice-search-service2-ap ID: /04/ :23:00 12/04/ :27:59 response Severity of alarm ehealth Event Data: Transaction Client Application Server [Severity]: major [Start Time]: 12/04/ :27:59 [Start Time(UTC)]: [Element Name]: orden-pc-custservice-search-service2-ap [Rule Message]: Response Time approaching threshold [Tech Type]: response [Variable]: Avg. Response Time [Problem Start Time]: 12/04/ :23:00 [Problem Start Time(UTC)]: Determine the Scope of the Problem. When Live Health sends an alarm, the on-call IT staff member checks the Live Status diagram to understand the scope of the problem. At Tuvw.com, Live Status is configured to reflect the infrastructure of the customer service application. With a quick glance at the diagram, the IT staff can determine whether an alarm indicates a problem for one or more groups or locations, servers, or network components. S ear c h r s S erve Customer Service Response D ele R oute r s_sw s i tche C red i tch Problems with 2 servers t e e ck R oute r _Core Figure 1. Live Status Diagram for a Web Application In this case, the Live Status diagram shows alarms for each of the monitored transactions for the CustService A cce s s a n L anw CustService Problems with all CustService transactions for this user group

4 4 application, as well as two server alarms. Because the transaction-related alarms appear for the first set of icons only, the IT staff can quickly see that users in one location (Chicago) are having trouble. With the problem identified, they can proceed to diagnose the source of the problem, as described in the next section. Value 2: Accelerate Diagnosis of Problems When Application Response indicates a degradation in Web performance, you can take full advantage of ehealth diagnostic capabilities to quickly pinpoint the problem. Drill-down reports can identify whether the problem is due to the client, the network, or the server, and whether the problem is limited to a particular application, location, or user group. With this information, you can quickly direct the appropriate IT resources to investigate and resolve the issue, so that users are impacted as little as possible. Drill Down for Details. To continue the case study from the previous section, Live Health has alerted IT personnel at Tuvw.com that their Web-based customer service application is experiencing performance problems, affecting representatives in their Chicago office. From the Live Status diagram (shown in Figure 1), an IT staff member right-clicks a Chicago client set icon and drills down to an At-a-Glance report to investigate the problem for all users in that office. S ear c h r s S erve Customer Service Response D ele R oute t e r s_sw s i tche C red i tch e ck R oute r _Core A cce s s a n L anw CustService The Transactions Observed chart of the At-a-Glance report shows a corresponding change in application activity: the transaction rate decreased sharply at the same time that the server response time began to increase. This performance problem is significantly impacting user productivity in Chicago. Determine Who Is Affected. The At-a-Glance report shows average performance statistics for all Chicago users. From the At-a-Glance report, an IT staff member drills down to a Top N report for a list of the Chicago users who are active during this time and affected by the server slowdown. The following Top N report shows that server response time is high for most users in the Chicago office. This information leads the IT staff to conclude that the problem is not related directly to a specific user but is a problem with the Web server that services the customer service application for the Chicago office. In the At-a-Glance report, the Average Response Observed chart shows a sharp increase in server response time for the past hour, pointing to a problem on the Web server for the customer service application.

5 5 inder-pc-rs fler-pc-rs gray-pc-rs K K 4.20 K K After the Web design team redesigned the site, the IT staff at Arno, Inc. made it available to a small group of users for a two-day period, and then ran an At-a-Glance report to check response times for the group. For each variable, the report shows two charts: one for local (high-speed) users, and one for remote (dial-up) users. This layout makes it easy to look for relationships between the variables. trist-w2k-rs 3.15 K orden-pc-rs 2.82 K Now that the IT staff has identified a problem in server response time for Chicago users, they can use other ehealth products and reports to investigate the server to look for the source of the problem. For example, they can run a Health report for the customer service Web servers to check for exceptions and situations to watch. They can also run an At-a-Glance report for the specific Web server to which the Chicago users are connecting to look for the source of the problem. Value 3: Monitor Response Times for High-Speed Access and Dial-Up Users Web page download times of one to two seconds are generally acceptable for most users. Download times in excess of ten seconds typically cause users to become impatient and frustrated, interfering with productivity. Application Response can measure the time required to download a Web page, showing total response time and its breakdown into client time, network time, and server time. It can also show the response times experienced by dial-up users and high-speed access users. With this information, you can measure changes in download times after updating or redesigning Web sites and ensure that dial-up users experience acceptable response times. A Case Study: Web Site Redesign. When Arno, Inc. decided to redesign its Web site, it wanted to ensure that, after the redesign, both high-speed access users and dialup users experience acceptable download times. Figure 2. Selected Charts of an At-a-Glance Report The first chart, Average Response Observed, shows that local users were experiencing a significant amount of client time (shown in green) until November 11, when client time was reduced by half. Remote users, however, were experiencing fast response time until November 11, when a sharp peak in network time (shown in yellow) occurred. The remaining two charts show that, for remote users, the number of round trips (from the client to the server and back) per transaction and the network time for

6 6 round trips increased at the same time that network time increased. Notice that network round trip time for local users also increased at that time, but it did not significantly affect average response time for these highspeed access users. The Arno IT staff showed the response time impact of the redesign to the Web design team. The team analyzed the site and discovered that a large number of new graphics required several round trips to retrieve and download. They changed the Web pages to use multiple occurrences of the same image instead of many different images. As a result, the image is stored in the user s cache after its initial download so that subsequent instances of the image can be rendered more quickly. This change resulted in faster download times for remote users. Value 4: Monitor Web Performance When Making Infrastructure Changes When you make changes to the infrastructure of a Web service, you need to make sure that the changes do not degrade response times for users. Application Response can compare current performance with past performance to determine how such changes affect a Web service. A Case Study: Human Resources Software. Employees at Waikato.org use a Web-based application named HRinfo to track their Human Resources information, such as benefits, vacation time, and paychecks. Waikato plans to upgrade the HRinfo application software, and they want to make sure that the upgrade does not affect response time for users. Before upgrading the software, the Waikato IT staff ran a Trend report to check current response times experienced by users of HRinfo. The report shows that response time is generally 20 seconds or less, with a few higher response times during busy periods. Response time before the software upgrade Before upgrading the software on the production Web server, the IT staff performed the upgrade on a test server. Then they performed sample transactions over a 48-hour period and ran the same Trend report to compare response times before and after the change. The resulting report shows significantly slower response times after the software upgrade. Response time for test transactions To investigate the source of the increase in response time, the IT staff ran an At-a-Glance report on the client set for the test clients. The Average Response Observed chart shows the breakdown of response time into client, network, and server time. This chart shows that the largest contributor to average response time is server time. The IT staff reviewed the upgrade release notes and learned that they need to tune

7 7 server parameters to accommodate new software functionality. After they changed parameters on the test server, response time for the HRinfo software returned to its previous levels. The IT staff then felt confident about upgrading the production server and performed the upgrade. After the upgrade, the IT staff continues to monitor HRinfo response time to watch for new performance problems. By running the Service Customer report, they can review Web performance each day to ensure that response time is not degrading. An increase in the number of transactions over 100% of threshold (shown in purple) indicates degradation in response time. The following report shows average response time over the past three weeks, with the last week reflecting the HRinfo software upgrade. The report shows that the number of transactions over 100% of threshold is relatively consistent, with prior weeks indicating that response time has not been significantly impacted. Value 5: Compare Current Versus Historical Performance Users sometimes report that an application seems slower than normal or performance is worse than usual. Application Response can help you to verify user perceptions of slow Web response. Its reports allow you to compare current Web performance with past performance to determine whether response time has changed and, if so, how much it has changed. Examine Actual End-User Response Times. Application Response monitors the actual response times that end users experience with Web services. For example, if a Boston user reports long delays when accessing your intranet, you can run a Trend report to examine that user s experiences for the past week. This report shows that the user s response times at the beginning of the week were less than one minute. In the second part of the week, however, the response times doubled, mostly due to increases in network and server time. After confirming the validity of the user s complaint, you can determine whether the problem is affecting this user only or all users in the Boston office. To check this, run an At-a-Glance report for the Boston client set (user group).

8 8 This report confirms that all Boston users are experiencing a similar increase in response time due to increases in server and network time. Now you can use other ehealth reports and tools to diagnose the cause of increased response time for Boston users who access the intranet. Make Reports Available to Users. As with all ehealth reports, you can schedule Application Response reports to run on a regular basis (daily, weekly, and monthly) and make these reports available to specified users. For example, you can configure ehealth to run an At-a- Glance report showing the past week s intranet response time for the Boston client set every Monday morning. This report can then be ed to the Boston branch manager automatically, posted on your corporate intranet where the manager can access it, or made available through the ehealth Web interface. This provides application managers, department managers, and others with up-to-date information about their end users experiences with mission-critical Web services. Value 6: Measure the Impact of Viruses and Power Outages on Web Performance The Internet has become a critical means of communication for most organizations, but it is vulnerable to attacks from worms, viruses, and other events, such as local power outages. These events can have a direct impact on your daily business and its profitability. When an Internet event occurs, you need to know the moment it begins to affect your business so that you can take steps to protect your organization and minimize the impact. You also need to know which parts of your business are affected so that you can prioritize and focus IT resources most effectively. Detect Worms and Viruses. Many Internet worms and viruses have typical behavior patterns: they increase the amounts of network and Internet traffic. As the level of Web activity increases, the response time experienced by Web users also increases, resulting in lower productivity and lost revenue. Application Response can identify sudden and unexpected changes in the level of Web activity. This capability helps IT staff to take action before a virus or worm spreads too far and affects Web performance. Detect Unusual Levels of Web Activity. ehealth determines normal behavior for Web users based on historical data. Live Health can look for deviations in behavior from the norm for variables such as the numbers of transactions, TCP connect attempts, and bytes sent and received. Significant changes in these variables may indicate that a worm or virus is affecting performance for Web users. For example, Mekong.org is concerned about the effect of Internet worms and viruses on its Web services. To watch for unusual Web activity, the IT staff configured Live Health to monitor the number of TCP connect attempts and issue a warning when it approaches three times the normal rate, indicating a potential threat. When the number of TCP connect attempts increases to five times the normal rate, Live Health raises a critical alarm, escalating the problem. Evaluate the Impact of a Worm or Virus. Mekong has configured a Live Status diagram to track performance for four mission-critical Web services: WebMail, Extranet, Intranet, and CustService. (Other diagrams track performance for additional business areas.) When a worm or virus attacks, the IT staff can use Live Status to quickly determine which areas of the business are impacted and take steps to protect the most critical areas. For example, when Live Status indicated that a virus was affecting Web response time for Mekong s extranet and intranet, they decided to focus efforts on the extranet first because the virus would directly impact sales and profitability there. W ebm a il W ebs e rvers W ebr I ntra o uters n et S witc Web Services h es E xtra W ebr n et o uterc o re C usts e rvic e WebServices n a nwa W ebl Something is affecting response time for the intranet and the extranet. Focus efforts on the extranet first to prevent loss of revenue.

9 9 Investigate Potential Internet Threats. When a Live Health alarm pointed to a possible virus, the Mekong IT staff investigated the problem by running a Trend report on the number of TCP connect attempts during the past week. The following sample Trend report shows that the current rate of TCP connect attempts (over 60 per minute) is more than three times the trend from the baseline (15 per minute). To further investigate the possibility of a virus, the IT staff ran an At-a-Glance report for the Web server and looked for changes in behavior for average response time, and the numbers of transactions and bytes (load on the network). When all data pointed to virus attack, Mekong took immediate steps to secure their environment and minimize its impact on Web services. to support the desired level of performance. Because Application Response identifies the infrastructure areas that are significantly impacting Web performance, you can plan to use your capital budget where it is needed most. When you need to justify capital expenditures, Application Response provides the statistical analysis to back up your plans. Capacity Planning for Web-Based Applications. For Web services, capacity planning refers to the process of ensuring that the infrastructure can support the total number of Web users performing peak Web loading at the desired service level. For example, Danube Corporation is growing and plans to add 50 new employees each month over the next year. The IT staff needs to know whether and when they must add a Web server to maintain service goals, and whether the network will require additional capacity to support the increase in network traffic. Look for Trends. To perform capacity planning with Application Response, the IT staff at Danube uses the group Trend report to examine average response time and the number of Web transactions over time. The following sample report shows that the number of transactions (green) has remained steady for the past month, and that response time (red) is generally 20 seconds or less. Determine the Impact of Local Power Outages on Business Services. Similar to the way in which you can use Application Response and Live Health to detect Internet worms and viruses, you can use these tools to measure the effects of local power outages or other problems on your business services. For example, when a hurricane caused regional power outages, a major toy retailer used a Live Status diagram to determine which locations were affected: some stores experienced slow response times, while other stores were completely shut down. This information allowed the toy retailer to determine the impact of the power outages on business. Value 7: Improve Capacity Planning Application Response can help you perform capacity planning to support your Web services infrastructure. With this information, you can plan ahead for upgrades to Web servers, client systems, and network components

10 10 Three months later, 50 new users per month have increased the number of transactions performed. For the first two months, this increase in Web activity did not affect performance. In the last month, however, response time appears to be degrading as a result of increased activity, with frequent peaks over one minute. To determine whether the increase in response time is due to the client, the network, or the server, the IT staff ran another group Trend report for the last month. This report reveals that server response times have increased significantly. With this information, the IT staff at Danube made plans to add another Web server to increase its capacity to support the new users. They will continue to monitor Web response time and watch for data that indicates the need for additional network capacity, as well. Where to Go from Here When you are ready to use Application Response to monitor Web applications, read Configuring Application Response to Monitor Web Applications for an overview of the process and step-by-step instructions.