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

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT against a preproduction environment are not fruitful you can only tune your application to the user load it is subjected to. In this section, you ll learn how to mitigate the performance impact of monitoring in a production environment and look at the following topics: Identifying the best time intervals to record data Choosing the correct subset of your production environment to monitor Recording production data using a staged approach Configuring the recording to compute metrics effectively Recording at the Right Intervals The first consideration when recording live production data is when to record it. The target is to identify a period of time within a day or a week with average user load, when users are performing actions representative of their typical behavior. For example, in the case of an intranet application that requires users to log on in the morning, perform daily activities, and log off before they leave, the login and logoff hours of the day are less representative of the majority of user actions a user logs in once but may generate a couple dozen reports throughout the day. Therefore, recording a 30-minute session with users logging in may distort your tuning efforts, causing you to spend too much time tuning seldom-used functionality while missing true performance tuning opportunities. An access log analyzer or user experience monitor can help you pinpoint the best opportunities during the day or week to capture average user activities. The time period you are looking for is when the user load is average you do not want a dramatically under- or overutilized time. If the application is underutilized, then you risk missing problems that only manifest under load; if the application is overutilized, then you run the risk that the monitoring overhead may negatively affect end users experience. The ideal time period exhibits the following characteristics: Eighty percent or more of the most frequently executed requests are being performed. User load is within one standard deviation of the mean user load. The key to effectively identifying this time period is to perform historical analysis of your log files or user experience monitor over a significant time period. Although the analysis of a single day s activity may reveal a seemingly ideal recording period, you can only confirm that period as ideal after looking at the entire week or even the entire month. When implementing proactive tuning measures, you want to ensure that you choose the appropriate recording time window to maximize your tuning efforts. Note Although in the big picture, choosing the correct recording interval is required to maximize tuning efforts, I have never let this point be a sticking point for me. Most companies know approximately when user activity is representative of typical behavior, so while I am sure to later validate the interval as representative, I follow the lead of the companies I m working with and record and analyze data at the intervals they identify.
If you are searching for cheap webhost for your web application, please visit MySQL5 Web Hosting services.

266 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Tip You might need to reduce overhead when your application is simply too large (with too many classes or too large of a call tree), or when you are testing only a subset of an application (you can inadvertently reduce overhead by simply not monitoring classes and requests that you are not interested in). The following common strategies can help you isolate problematic sections of code, even when overhead is not an issue: Filters: Only record requests that you are interested in and filter everything else out. Custom components: When integrating external libraries or code your requests interact with, but that you have no interest in seeing detailed call traces for, you can roll calls in these classes or packages into black boxes referred to as custom components. The purpose of implementing filters and custom components is to narrow the scope of user requests that you have to review to assess the health of your application. Considering the sheer size of an enterprise application, performance tuning can be a daunting task, and if you can eliminate items that you do not care about and have no control over, you can reduce the overall amount of data you analyze and more efficiently identify real problems. Production Strategy While the goal in the preproduction strategy is to obtain a reasonably detailed level of information about the components and requests you are interested in, production recording adds the caveat that you do not want to noticeably impact the end-user experience. When you gather information from a production environment, performance impact must take precedence over level of detail. As you will see, you can still gather a similar level of detail, but in a staged approach. Before diving directly into production, let s consider the two primary reasons for recording real-life users as they are executing an application: Production behavior cannot be reproduced in a preproduction environment. We want to gain a true understanding of end-user behavior. Obtaining these real-life user behaviors is important because most customer sites that I visit maintain large enterprise environments, so when a performance issue occurs, it is very difficult to reproduce it in a controlled environment because of the sheer number of moving pieces. In this situation, there are two strategies: Record user requests from production and replay them in a controlled environment. Jump into production to diagnose the problem. Regarding the first strategy, new tools are emerging that can record live production usage and replay it against another environment, such as a test or preproduction environment. Because of their newness, though, these tools have not been widely adopted. Most companies opt for the second strategy of diagnosing the problem in production. If production usage cannot be reproduced in a preproduction environment, then tuning efforts
Go visit our java server pages services for a reliable, lowcost webhost to satisfy all your needs.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT What is the average load (requests per time period/simultaneous requests)? What is the peak load? Most of these questions can be answered using a good parser if you cannot afford a commercial access log analyzer offering. Extracting the desired information from the access logs is a nontrivial undertaking, but not overwhelming. Evaluating Critical Mass With balanced and representative requests, you next need to determine the critical mass of your application. In other words, you need to know what amount of load and/or what amount of time causes your application to create all of the components, fill all the pools, and generate typical caching behavior that it is representative of your production environment. You can learn a lot from watching your application achieve critical mass, but the performance assessment is primarily concerned with the behavior of your application once critical mass has been achieved. Configure your load tester to ramp up and cause the application to reach critical mass before recording performance information. Failure to do so may cause you to spend time investigating performance anomalies that only occur on start-up, such as the compilation of a JSP. In this case, the solution is to precompile the JSP, but if you are capturing performance information, the aggregated response time value may be skewed by the compilation time and send you on a fruitless tuning effort. Determining User Load You need to size the amount of load against the environment to closely resemble your production traffic (scaled down to your preproduction environment, of course). When implementing a performance assessment, it is not crucial that your load match exactly, but you need to fall within an acceptable range. If your production load is about 500 users and you test with 400, your results should be fine, but if you test with 50, then your test results cannot be completely trusted. Some performance issues only manifest under significant load, such as the impact of session sizes and the creation of temporary objects. For example, maintaining a 1MB session may not present a problem with 50 users, but with 500 it can quickly eat up your heap. Likewise, creating a handful of objects to satisfy 50 users (with appropriate think times) may allow plenty of time for garbage collection, but objects for 500 users may flood the application and force premature object tenuring, increasing the frequency and duration of major garbage collections. The point is that a lot of unexpected events can happen when an application is subjected to load, so when performance testing your application, you must do so under load. Recording Metrics Because you are recording in a preproduction environment, the best strategy is to capture as much meaningful data as you can. This means that you should record application server and operating system statistics at a fine-grained interval for example, every minute or even every 30 seconds and you should record detailed application metrics using bytecode instrumentation. You can employ other strategies to minimize the overhead of application-level monitoring, but typically they can be omitted in a preproduction environment.
In case you need quality webspace to host and run your web applications, try our personal web hosting services.

264 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Assessing Usage Patterns After you have set up your preproduction environment, the next major task you are faced with performing is a usage pattern assessment, to understand what your users are doing and in what balance they are doing it. The usage pattern assessment again refers to identifying balanced and representative requests; your tuning efforts are only as good as the load you send against your environment. Balanced and representative requests were required for performance tuning and capacity assessments and they are also required for performance assessments inside a preproduction environment. Without balanced and representative requests you may waste time tuning code that is seldom executed, and you might miss code that experiences significant performance issues when subjected to usage patterns that do not match your tests. Access log analyzers and user experience monitors can help you understand users behaviors. Web servers can be configured to record all requests made against them, and typically these requests are stored in a file named access.log, although the storage location can vary among vendors. An access log analyzer can parse this log file and display the top requests as well as report the frequency of each request. From this analysis, you can better design your load scripts to mimic your end users behavior. The difficulty that parsing access logs presents is that access logs report only URL requests and not parameters passed to those URLs in other words, access logs are not application aware; they are only URL aware. User experience monitors, on the other hand, are physical devices that sit on your network and watch requests as they happen in real time. Typically, you can preconfigure them with knowledge about your application so they re able to identify application functionality as opposed to simply reporting URLs. Another difference between access logs analyzers and user experience monitors is that access logs do not typically report request response times, but user experience monitors do. Not only do user experience monitors report response times, but also they can be configured to fire alerts (for example, send e-mails or even launch application processes) when SLAs are exceeded. It is worth noting that access log analyzers are mostly used by marketing departments to identify user demographics and behavior as well as assess the efficacy of marketing dollars. An access log analyzer attempts to answer the following questions: What path did the user get to a particular page? What types of advertising, such as banners, have been effective? What part of the country/world is the user located? What are the most popular pages/documents on the site? Therefore, with respect to assessing user behavior, you do not need the most expensive log analyzer you really need only answers to the following questions: What are the top pages being viewed? In what order are users visiting pages? (You determine this by tying together user requests by IP address and aggregating log entries into approximate transactions.) What are the average think times between requests within a transaction? What are the average think times between transactions?
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision J2ee Web Hosting services.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Preparing the production environment Assessing usage patterns Evaluating critical mass Determining user load Recording metrics We examine each task in more detail in the sections that follow. Preparing the Production Environment You need to prepare either a mirrored or scaled-down version of your production environment to test against. From a mirrored environment, you can assess the exact behavior of your production environment without requiring extrapolation, but from a scaled-down version, you will have to extrapolate the performance of the preproduction environment to the production environment. As a general rule here, as with everything in your job, make your work as easy as possible! Unless it is completely unavoidable, do not try to test an application in JBoss on a single-CPU Intel machine running Linux when the application is destined to be deployed to WebLogic on a quad-processor Sun machine running Solaris. Doing so will make your extrapolations synthetic and error-prone. The best strategy is to attempt to make the extrapolations as linear as possible. To do this, try to build a test environment with the same class of machines as in your production environment and with an evenly divisible number of machines and/or CPUs. For example, if your production environment consists of eight machines in the application server tier, then two of the same machines could suffice in your preproduction environment. Furthermore, if your production environment has eight CPUs in each machine, then two or four might suffice in preproduction (it s trickier to extrapolate performance projections about CPUs than the number of machines). The point is that if you scale down the number of machines and CPUs evenly, then your extrapolations will be easier to perform and less error-prone. Note When you read linear here, keep in mind that there is no such thing as true linear extrapolation in enterprise environments. While one machine may service 200 users, it does not necessarily mean that two machines can service 400 users, because with a second machine you have potentially introduced additional state replication across your network as well as remote resource references (such as accessing a cached entity bean residing on a different machine). Extrapolation is a difficult process, especially when network communications are involved, and there is no single reliable formula to help you, because the variables that impact scalability include your availability and failover implementations, replication strategy, replicated object size, hardware and network configuration, and mix and configuration of horizontal and vertical servers. In practice, you can derive this extrapolation value with your own tests and be equipped to more accurately estimate through scaled-down observations than with any formula I could provide you.
Searching for affordable and proven webhost to host and run your servlet applications? Go to Linux Web Hosting services and you will find it.

262 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Filters Filters control what requests or request patterns are recorded. For example, to record all requests into the myapp Web context, you would configure a filter to record all requests matching /myapp/* and exclude all others. Filters can be used to greatly reduce the number of requests that are traced and hence have the biggest impact on performance monitoring overhead. It is common to write a performance analysis report for a single application, and this is possible by implementing filters. Level of Detail The level of detail configures whether the tool captures full call stacks at the method level, only significant components, or simply requests. The finer the level of detail, the greater the overhead. Method-level recordings provide complete call stacks from an HTTP request, through application classes and methods, and to back-end dependencies such as databases, offering the finest level of detail and the best information, but at the highest overhead. Component recordings, or boundary recordings, can aid you in identifying poorly performing parts of your application. A typical component recording breaks down how much time each request spent in the Web tier, Web architecture (such as Struts), EJB tier, JDBC calls, and so forth. Finally, request-level recordings provide an overview of all requests executed during a recording, the number of times they were executed, and their minimum, maximum, and average response times. Request-level recordings are good for identifying candidates for method-level recordings in subsequent tests. Custom Components Custom components group classes and/or packages together into a black box: the call enters the black box, does some stuff, and then either returns or makes calls out of the black box. The tool captures and records the response time of the entire black box, but does not provide detailed call traces for it. Good candidates for custom components are third-party libraries. For example, if you use JDOM to parse your XML files, it suffices to know the overall contri bution of JDOM to response time you do not need to know the intricacies of where JDOM is spending all of its time. After all, if you find a performance problem (which is still visible by using the custom component), it does not do you any good to isolate the root cause of the problem, because you cannot change the code. Of course, if you are a nice person, then you can isolate the problem and report back the root cause to the development community to enhance the product in the future, but the root cause of a JDOM problem does not belong in your performance analysis report. Preproduction Strategy We start performance analysis in preproduction because ideally, if you can reproduce user load, preproduction is the best environment to test in. Here, you can subject the environment to as much load and overhead as is required to identify performance issues. For your testing efforts to be effective, you need to do a little bit of legwork first, including the following:
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check mysql web server services.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT return raw metrics and allow the calling program to derive values from the raw metrics, but the point is that it is all accomplished with a single HTTP call. Again, you are required to deploy an additional Web application to your environment in order to implement such an architecture. Application Recording Application recording involves bytecode instrumentation that traces requests as they happen, so application recording overhead cannot be mitigated by adjusting the time of snapshots. A snapshot of running methods would be almost worthless, but a list of processed requests with their associated call traces aggregated for a specific time interval is incredibly valuable. Therefore, the strategies we employ to mitigate performance overhead when recording application requests are more complicated. They fall into the following categories: Sampling percentage Sampling period/aggregate period Filters Level of detail Custom components I discuss each category in the sections that follow. Sampling Percentage Bytecode instrumentation differs from metric recording in that while metric recording can be performed at regular intervals by taking snapshots (for example, capturing at a specific time how many threads are in use or how many database connections are open), processed requests must be captured when they occur and aggregated at specific intervals. Therefore, your byte- code instrumentation tool should be configurable for the percentage of requests to trace as well as the interval to aggregate request information (that is, report how many times each request, class, and method was executed, and their average, high, and low response times). The higher the percentage of requests traced and the more frequent the aggregate period, the greater the performance overhead. But the higher the percentage of requests traced and the more frequent the aggregate period, the easier it is to accurately isolate a single request for troubleshooting. As with all performance tuning options, it is a balance between overhead and quality of data. Sampling Period/Aggregate Period In addition to configuring the percentage of requests to sample, you need to configure the time period in which to aggregate those samples. Capturing and storing every request is unwieldy from a storage perspective when you can glean significant insight by aggregating those samples over a time period and reporting back the average response time, maximum response time, execution count, and so on. The configuration of this time period, however, can greatly affect the overhead inflicted on the environment. For example, aggregating performance information every ten seconds requires more frequent computations than aggregating performance information every minute. But the trade-off is that if an individual request performs poorly, it is easier to find and analyze it if the aggregate period is small.
Please visit our professional web hosting services to find out about cheap and reliable webhost service that will surely answer all your demands.

260 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT The first point is straightforward. For example, the maximum number of threads that can exist in a thread pool is not going to change very often; therefore, you do not need to gather that information on each sample. But be warned that what initially may appear to be configuration metrics may in actuality change more frequently than you would expect. Growable thread pools are a prime example of this. There is a difference between the maximum number of threads that can exist in the thread pool at any given time and the total number of threads that currently exist. In the past, this has led to some confusion when I observed thread pool usage spike to over 150 percent: the thread pool usage was defined as the number of threads in use divided by the total number of threads, but the total number of threads changed as the thread pool grew. So while the total number of threads appeared to be a configuration parameter, it was a dynamic value that needed to be sampled more frequently than it was. The second point sounds good in theory, but it is difficult to use in practice, especially in a performance analysis report. The reason in interactive monitoring applications is that when you expand a node or drill down into a detailed metric, you usually want to see the graph prepop ulated with at least the last several minutes of data. And by definition, the detailed information is obtained when it is requested, thereby negating this expected behavior. The reason that this is not possible when building a performance analysis report is that the analysis is typically performed after the fact, when it is too late to capture detailed information. The final solution may be to integrate a strong analysis engine that can dynamically capture detailed information when specific conditions occur, but at the time of this writing tools with this characteristic do not exist. Depending on your requirements, this effort to reduce monitoring overhead may be possible, but you do need to realize the implications. The final configuration that can impact monitoring overhead is ingrained in your moni toring tool: how does it obtain its performance information? Is it touchless, or is it through a mechanism installed on your application server? A touchless architecture has been a real selling point that has some benefits: you spend time up front configuring your monitoring tool, but then by specifying connection information, you can connect to any application server instance (or administration server). Typically you need to match up remote protocol library versions, but once that is accomplished, you can easily connect to any server or cluster in your environ ment. The alternate architecture is to first deploy some communication mechanism (such as a servlet) to the environment and then point your monitoring tool at the servlet. Each server that you want to monitor needs to have this servlet deployed to it, but then the monitoring tool does not need any remote protocol libraries; it works over standard HTTP. From this description, it may sound as though the touchless architecture is less intrusive in your environment because you do not need to deploy any code to it. But recall Chapter 4, where we implemented performance measurements by writing a servlet that read the JMX registry and returned the requested data. It required several calls to obtain even a small subset of information. In a touchless architecture, monitoring software can obtain information in one of two ways: bulk calls and individual remote calls. The bulk mechanisms return more data than you are necessarily interested in and still require a plethora of remote calls. Neglecting to obtain information in bulk results in more remote calls than you can count. Either way, the network overhead and processing overhead required to handle the remote calls severely impacts the performance overhead of a touchless architecture. The traditional architecture is to deploy a servlet to the application server instances and then make calls to it. In this architecture, the servlet can make all of the calls locally and return all pertinent information in a single network call. To mitigate the performance impact, it can
From our experience, we can recommend PHP Web Hosting services, if you need affordable webhost to host and run your web application.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT it is important to understand what affects performance monitoring overhead, so this section explores some common configuration options that can mitigate performance overhead in two distinct areas: Platform recording Application recording Platform Recording Platform recording includes the entire layered technology stack upon which a Java EE application runs, specifically the following: Application server JVM Operating system Hardware Typically when you record platform metrics, you use a tool to capture periodic snapshots of the current state of the platform, including such metrics as the number of threads in use and the number of database connections in use. The tool then presents summaries of multiple snapshots, sometimes in graphs, from which you can assess the health of the various platform components. For example, knowing that during a one-hour test session the minimum number of threads in use was 7 and the maximum number of threads in use was 48, out of a total of 50, might lead you to increase the thread pool size to provide enough of a buffer to satisfy usage peaks. Statistically speaking, capturing performance metrics in this snapshot fashion provides a representative view into the performance of a platform component. But the accuracy of the representation depends wholly on the length of the recorded session and the interval upon which the metrics are captured. For example, capturing performance metrics every 5 minutes over a 1-week period is sufficient to provide an accurate representation of the platform behavior. But capturing performance metrics every 5 minutes for a 30-minute recorded session hardly yields conclusive results. In a 1-week period, 5-minute samples will converge on the representative behavior, but in a 30-minute period, a finer granularity of sampling is required. Therefore, the sampling interval needs to be appropriately chosen to mitigate performance overhead: you need to balance the granularity of samples between performance overhead and usefulness of the captured data. Ensure that you are capturing information that will help you tune the platform, while not bringing the platform to its knees in the process. The amount of data captured in a snapshot likewise affects the performance overhead of monitoring. For example, if a snapshot includes the entirety of an application server s JMX registry, then capturing this information even every minute adds significant burden to the application server. To mitigate this impact on performance overhead, employ the following strategies: Gather configuration information less frequently than run-time information. Consistently gather cursory or summary information, but gather detailed information only once it has been requested.
In case you need quality webspace to host and run your web applications, try our personal web hosting services.

258 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Once you understand the expected performance of your application, put the proper monitoring frameworks in place, build a representative production staging environment, and have an accurate load generation tool, then you are ready to begin your performance assessment. Process The implementation process of a performance assessment for a preproduction environment and for a live production environment is different. In a preproduction environment, you maintain control of the load, the user ramp-up time, and the user behavior, whereas in a production environment, the user maintains control of these factors. Furthermore, in a preproduction environment you are free to generate as much load on the system as necessary, including monitoring overhead, but in a production environment, you want to gather valuable information without your users noticing performance degradations. The latter sections of this chapter describe the best-practice strategies for obtaining performance information, both from a preproduction environment and a production environment. But regardless of how you capture the data, the goal is to obtain performance statistics at each relevant point in your environment, including statistics from inside your application, while users (either synthetic or real) are actively using your application. Analysis With performance statistics in hand, your goal is to transform this raw data into derived business values. For example, a saturated thread pool with pending requests is a raw value, but the interpretation that pending requests equates to waiting users, and hence the degradation of service request response times can be applied as a business value to your company, for example: The result of the undersizing of this thread pool is that business processes cannot satisfy their SLAs, which puts the company in violation of its contractual obligations. Sometimes people especially technical people get caught up in low-level details, without taking the time to understand the business implications. In the past, I have spent time implementing features that are cool, but do not satisfy consumer demand, and I have spent time tuning complicated functionality that is seldom accessed. But as the Java EE system administrator, you need to understand both the technical implications of performance statistics and how those implications affect your company s business processes. Furthermore, you need to be able to articulate the business process implications in a performance assessment report to your superiors, to provide them with enough information to make business-level decisions (for example, whether functionality ABC takes priority over functionality XYZ). Interpreting raw statistics and assessing their impact on business process is somewhat of an art and is dependent on your specific application and environment. In this chapter, I provide general guidelines detailing how to interpret direct metrics as well as how to interpret the implications of abnormal application behavior, or indirect metrics. Through this analysis you can accurately assess the health of your enterprise environment. Mitigating Performance Overhead As mentioned earlier, by merely observing a system, we affect its behavior. As such, every monitoring tool needs facilities to control the level of observable impact it subjects its environment to. As a precursor to learning about preproduction and production monitoring strategies,
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check mysql web server services.