Web host forum - CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT
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.