Inexpensive Web Hosting - J2EE Hosting Sun Java, Mysql5, Java, Jsp, Servlet Developing Blog

CHAPTER 6 Performance Tuning Methodology I have been reading about performance tuning on our application server vendor s Web site, and it looks so complicated. There are all of these ratios that I need to watch and formulas to apply them to. And which ones are the most important? What s going on with this? John was getting frustrated with his tuning efforts. He had his team implementing the proactive performance testing methodology that I helped him with, but the concept of the bythe- book performance tuning was evading him. Don t let those ratios fool you there is a much better approach to performance tuning. Let me ask you, when you take your car in for service, does the service technician plug your car into a computer and tell you what s wrong with it, or does he ask you to describe your problems? Well of course he asks me about my problems, otherwise how would he know where to start looking? A car is a complicated machine, John replied. Exactly. There are so many moving parts that you wouldn t want to look at each one. Similarly, when tuning an enterprise application, we want to look at its architecture and common pathways to optimize those pathways. When we step back from application server ratios and focus on what the application does and how it uses the application server, the task becomes much easier. From the look on his face, I could see that he got it. He saw that the focus of tuning should be on the application, not on abstract ratios that he did not understand. Performance Tuning Overview Performance tuning is not a black art, but it is something that is not very well understood. When tasked with tuning an enterprise Java environment, you have three options: You can read through your application server s tuning documentation. You can adopt the brute-force approach of trial and error. You can hire professional services. The problem with the first approach is that the application server vendor documentation is usually bloated and lacks prioritization. It would be nice to have a simple step-by-step list of tasks to perform that realize the most benefit with the least amount of effort and the order in which to perform them, but alas, that does not exist. Furthermore, when consulted on best
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision virtual web hosting services

154 CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE Figure 5-14. Performance metrics for the application server during this recorded session Summary In this chapter, you learned how to integrate proactive performance testing throughout the development life cycle. The process begins by integrating performance criteria into use cases, which involves modifying use cases to include specific SLA sections that include performance criteria for each use case scenario. Next, as components are built, performance unit tests are performed alongside functional unit tests. These performance tests include testing for memory issues, and code issues, and the validation of the coverage of tests to ensure that the majority of component code is being tested. Finally, as components are integrated and tested in a production staging environment, application bottlenecks are identified and resolved. In the next chapter, we ll look at a formal performance tuning methodology that allows you to maximize your tuning efforts by tuning the application and application server facets that yield the most significant improvements. By the end of the next chapter, you ll be empowered to bring your application and environment to within 80 percent of their ideal configuration, regardless of your deployment environment.
Note: If you are looking for best quality webspace to host and run your tomcat application check Vision virtual web hosting services

CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE As shown in Figure 5-13, looking at the average exclusive time for each method that satisfies the POST /patient/register.do service request, the HTTP POST at the WebLogic cluster consumed on average 35.477 seconds of the 35.754 total service request average, which is important because the request passed quickly from the Web server to the application server, but then waited at the application server for a thread to process it. The remainder of the request processed relatively quickly. Figure 5-13. Breakdown of response time for the POST /patient/register.do service request for each method in a hierarchical request tree Figure 5-14 shows a view of the performance metrics for the application server during this recorded session. This screen is broken into three regions: the top region shows the heap behavior, the middle shows the thread pool information, and the bottom shows the database connection pool information. Figure 5-14 confirms our suspicions: the number of idle threads during the session hit zero, and the number of pending requests grew as high as 38. Furthermore, toward the end of the session, the database connection usage peaked at 100 percent and the heap was experiencing significant garbage collection. This level of diagnosis requires insight into the application, application server, and external dependency behaviors. With this information, you are empowered to determine exactly where and why your application is slowing.
Note: In case you are looking for affordable and reliable webhost to host and run your business application check Vision php5 hosting services

152 CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE Finally, most enterprise-scale applications interact with external resources that may or may not be under your control. In the most common cases, enterprise applications interact with one or more databases, but external resources can include legacy systems, messaging servers, and, in recent years, Web services. As the acceptance of SOAs has grown, applications can be rapidly assembled by piecing together existing code that exposes functionality through services. Although this capability promotes the application architect to an application assembler, permitting rapid development of enterprise solutions, it also adds an additional tier to the application. And with that tier comes additional operating systems, environments, and, in some circumstances, services that can be delivered from third-party vendors at run time over the Internet. The first step in identifying performance issues is to establish monitoring capabilities in your integration and production staging environments, and record the application behavior while under load. This record lists service requests that can be sorted by execution count, average execution time, and total execution time. These service requests are then tracked back to use cases to validate against predefined SLAs. Any service request whose response time exceeds its SLA needs to be analyzed to determine why that s the case. Figure 5-12 shows a breakdown of service requests running inside the MedRec application. In this 30-second time slice, two service requests spent an extensive amount of time executing: GET /admin/viewrequests.do was executed 12 times, accounting for 561 seconds, and POST /patient/register.do was executed 10 times, accounting for 357 seconds. Figure 5-12. Breakdown of service requests running inside the MedRec application
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision web design programs services

CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE Production Staging Testing Seldom will your applications run in isolation; rather, they typically run in a shared environment with other applications competing for resources. Therefore, testing your applications in a staging environment designed to mirror production is imperative. As the integration test phase is split into two steps, so is the production staging test: Performance production staging general test Performance production staging load test The general test loads the production staging environment with a small user load with the goal of uncovering any egregiously slow functionality or drained resources. Again, this step is interjected before performing the second, full-load test, because a full-load test may completely break the environment and consume all resources, thereby obfuscating the true cause of performance issues. If the application cannot satisfy a minimal amount of load while running in a shared environment, then it is not meaningful to subject it to excessive load. Identifying Performance Issues When running these performance tests, you need to pay particular attention to the following potentially problematic environmental facets: Application code Platform configuration External resources Application code can perform poorly as a result of being subjected to a significant user load. Performance unit tests help identify poorly written algorithms, but code that performs well under low amounts of user load commonly experiences performance issues as the load is significantly increased. The problems occur because subtle programmatic issues manifest themselves as problems only when they become exaggerated. Consider creating an object inside a servlet to satisfy a user request and then destroying it. This is no problem whatsoever for a single user or even a couple dozen users. Now send 5,000 users at that servlet it must create and destroy that object 5,000 times. This behavior results in excessive garbage collection, premature tenuring of objects, CPU spikes, and other performance abnormalities. This example underscores the fact that only after testing under load can you truly have confidence in the quality of your components. Platform configuration includes the entire environment that the application runs in: the application server, JVM, operating system, and hardware. Each piece of this layered execution model must be properly configured for optimal performance. As integration and production staging tests are run, you need to monitor and assess their performance. For example, you need to ensure that you have enough threads in the application server to process incoming requests, that your JVM s heap is properly tuned to minimize major garbage collections, that your operating system s process scheduler is allotting enough CPU to the JVM, and that your hardware is running optimally on a fast network. Ensuring proper configuration requires a depth of knowledge across a breadth of technologies.
Note: In case you are looking for affordable and reliable webhost to host and run your business application check Vision ftp web hosting services

150 CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE QA performs the integration general test under minimal load; the amount of that load is a subset of the expected load and defined formally in the test plan. For example, if the expected load is 1,500 simultaneous users, then this test may be against 50 users. The purpose of this test is to identify any gross performance problems that might occur as the components are integrated. Do not run a full-load test, because in a failed full-load test it may be difficult to identify the root cause of the performance failure. If the load is completely unsustainable, then all aspects of the application and environment will most likely fail. Furthermore, if the integrated application cannot satisfy a minimal load, then there is no reason to subject it to a full load. After the application has survived the performance integration general test, the next test is the performance integration load test. During this test, turn up the user load to the expected user load, or if you do not have a test environment that mirrors production, then use a single JVM scaled down appropriately. For example, if you are trying to support 1,500 users with four JVMs, then you might send 400 users at a single JVM. Each use case that has been implemented in this integration is tested against the formal use case SLAs. The performance integration load test is probably the most difficult one for the application to pass, but it offers the ability to tune the application and application server, and it ensures that the performance of the application stays on track. Balanced Representative Load Testing Probably the most important aspect of performance tuning in integration or staging environments is ensuring that you are accurately reproducing the behavior of your users. This is referred to as balanced representative load testing. Each load scenario that you play against your environment needs to represent a real-world user interaction with your application, complete with accurate think times (that is, the wait time between requests). Furthermore, these representative actions must be balanced according to their observed percentage of occurrence. For example, a user may log in once, but then perform five searches, submit one form, and log out. Therefore the logon, logoff, and submission functionalities should each receive a balance of one-eighth of the load, and the search functionality should receive the remaining five-eighths of the load for this transaction. If your load scripts do not represent real-world user actions balanced in the way users will be using your application, then you can have no confidence that your tuning efforts are valid. Consider this example if the actions were not balanced properly (say each action receives one-fourth of the load). Logon and logoff functionalities may be far less database-intensive than search functionality, but they may be much heavier on a JCA connector to a Lightweight Directory Access Protocol (LDAP) server. Tuning each function equally results in too few database connections to service your database requests and extraneous JCA connections. A simple misbalance of respective transactions can disrupt your entire environment. There are two primary techniques to extracting end-user behaviors: process access log files or add a network device into your environment that monitors end-user behavior. The former is the less exact of the two but can provide insight into user pathways through your Web site and accurate think times. The latter is more exact and can be configured to provide deeper insight into customer profiling and application logic.
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision best web hosting services

CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE Figure 5-11. A look inside the JThumbnailPalette s paint() method Performance in Quality Assurance The integration of components usually falls more on development than on QA, but the exercise usually ends at functional testing. Development ensures that the components work together as designed, and then the QA team tests the details of the iteration s use cases. Now that your use cases have performance criteria integrated, QA has a perfect opportunity to evaluate the iteration against the performance criteria. The new notion that I am promoting is that an application that meets all of its functional requirements but does not satisfy its SLAs does not pass QA. The response by the QA team should be the same as if the application is missing functionality: the application is returned to development to be fixed. Performance integration testing comes in two flavors: Performance integration general test Performance integration load test
Note: In case you are looking for affordable webhost to host and run your servlet application check Vision servlet hosting services

148 CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE Figure 5-10. Coverage profile of a graphical application The test exercised all six classes, but missed a host of methods and classes. For example, in the JThumbnailPalette class, the test completely failed to call the methods getBackgroundColor(), setBackgroundColor(), setTopRow(), and others. Furthermore, even though the paint() method was called, the test missed 16.7 percent of the lines. Figure 5-11 shows the specific lines of code within the paint() method that the test did not execute. Figure 5-11 reveals that most lines of code were executed 17 times, but the code that handles painting a scrolled set of thumbnails was skipped. With this information in hand, the person needs to move the scroll bar, or configure an automated test script to move it, to ensure that this piece of code is executed. Coverage is a powerful profiling tool, because without it, you may miss code that your users will encounter when they use your application in a way that you do not expect (and rest assured, they definitely will).
Note: In case you are looking for affordable webhost to host and run your servlet application check Vision servlet hosting services

CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE Figure 5-9. Profiling the bubbleSort() method By profiling the bubbleSort() method, we see that 45 percent of its time is spent comparing items, and 25 percent is spent managing a for loop; these two lines account for 56 cumulative seconds. Figure 5-9 clearly illustrates the core issue of the bubble sort algorithm: on line 15 it executes the for loop 12,502,500 times, which resolves to 12,479,500 comparisons. To be successful in deploying high-performance components and applications, you need to apply this level of profiling to your code. Coverage Profiling Identifying and rectifying memory issues and slow-running algorithms gives you confidence in the quality of your components, but that confidence is meaningful only as long as you are exercising all or at least most of your code. That is where coverage profiling comes in; coverage profiling reveals the percentage of classes, methods, and lines of code that are executed by a test. Coverage profiling can provide strong validation that your unit and integration tests are effectively exercising your components. In this section, I ll show a test of a graphical application that I built to manage my digital pictures running inside of a coverage profiler filtered according to my classes. I purposely chose not to test it extensively in order to present an interesting example. Figure 5-10 shows a class summary of the code that I tested, with six profiled classes in three packages displayed in the browser window and the methods of the JThumbnailPalette class with missed lines in the pane below.
Note: In case you are looking for affordable webhost to host and run your servlet application check Vision ecommerce web hosting services

146 CHAPTER 5 PERFORMANCE THROUGH THE APPLICATION DEVELOPMENT LIFE CYCLE We view the method response times sorted by cumulative time, because some of the algorithms make repeated calls to other methods to perform their sorting (for example, the quickSort() method makes 5,000 calls to q_sort()). We have to ignore the main() method, because it calls all seven sorting methods. (Its cumulative time is almost 169 seconds, but its exclusive method time is only 90 milliseconds, demonstrating that most of its time is spent in other method calls namely, all of the sorting method calls.) The slowest method by far is the bubbleSort() method, accounting for 80 seconds in total time and 47.7 percent of total run time for the program. The next question is, why did it take so long? Two pieces of information can give us insight into the length of time: the number of external calls the method makes and the amount of time spent on each line of code. Figure 5-8 shows the number of external calls that the bubbleSort() method makes. Figure 5-8. The number of external calls that the bubbleSort() method makes This observation is significant in order to sort 5,000 items, the bubble sort algorithm required almost 12.5 million comparisons. It immediately alerts us to the fact that if we have a considerable number of items to sort, bubble sort is not the best algorithm to use. Taking this example a step further, Figure 5-9 shows a line-by-line breakdown of call counts and time spent inside the bubbleSort() method.
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check Vision mysql hosting services