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

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT 285 Component Pools Stateless EJB components such as stateless session beans and message-driven beans are maintained in a pool to avoid creating and destroying them on a per-request basis. They are implemented this way for the same reason that JDBC connections are maintained in a pool: it is more efficient to check an object out of a pool than to create it. Being similar to connection pools, component pools are analyzed using the same metrics: Pool utilization Requests waiting for an object And as before, the analysis is defined as follows: The peak usage should not grow above 80 percent for any significant period of time. The average usage should be in the range of 50 to 70 percent. No threads should be waiting for connections. Periodic occurrences of five or fewer waiting threads are acceptable, but anything more should trigger a critical alert. If the number of waiting threads grows to the number of connections in the pool, then issue a fatal alert. The component pool is saturated and can recover only if the user load diminishes. Typically, the default application server component pool sizing is sufficient, but it is something specific that should be checked in a performance analysis report. Note Component pool sizing presents a theoretical problem, but in practice it is not very problematic. Components are not as expensive to create as database connections and are usually small in size, so application server vendors typically size them very large (for example, I have seen some sized to 1,000, and others can grow indefinitely). To put component pool tuning in perspective, I have to tune database connection pool sizes during almost all tuning engagements, but I have never had to adjust the size of a component pool. Message Servers Message servers are interesting in enterprise environments: they are either not used at all or used very cursorily, or they are an integral part of an application technology stack. In the former, they appear to facilitate asynchronous business processes, such as sending confirmation e-mails. In the latter, they usually appear as integration mechanisms between systems, typically integrating an application server with a mainframe application. The metrics involved in analyzing the performance of message servers are as follows: Message and/or byte upper threshold (If an upper threshold constrains how many messages or how many bytes can reside in the message server at any given time, then what is it?) Current number of messages/bytes in the message server Number of messages rejected from the message server
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision J2ee Web Hosting services.

284 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT If the cache is sized too small and this process occurs frequently, then the cache is said to be thrashing, meaning the caching infrastructure is spending more time managing the cache then servicing requests. The size of the cache has to be large enough to minimize thrashing, but remain cognizant of its memory requirements. If the only way to reduce thrashing is to size the cache unusually large, then you need to consider whether the object should be cached at all. I have been at customer sites where I have told the customer that objects are not being accessed frequently enough to justify a cache and they should request those objects from a database every time they are needed. For example, one customer maintained documents in an entity bean cache, but when the cache was sized at 1,000 beans, they had a 100 percent miss count. By parsing access logs it was determined that in an hour 7,000 different documents were being requested, and the average time between requests for the same object was over an hour. In order to satisfy these requests from cache with a minimum amount of thrashing, they would require a cache that held more than 5,000 objects. This simply is not practical, so I advised them to forego their cache altogether. When analyzing the performance of a cache, consider the following performance metrics: Passivation count: The removal of an object from the cache Activation count: The addition of an object to the cache Passivation rate: The rate that objects are removed from the cache (for example, objects removed per second) Activation rate: The rate that objects are added to the cache (for example, objects added per second) Hit count: The number of requests satisfied by the cache Miss count: The number of requests not satisfied by the cache When a cache is being populated, its hit count will be zero and its activation rate will be high, but when the application has reached its steady state and the cache is populated, then these metrics are valuable. Usually to avoid start-up anomalies, we analyze the miss count as a percentage (miss count divided by number of requests) and the passivation rate in relation to the size of the cache. The metrics are interpreted as follows: If the miss count averages greater than 30 percent, then the cache is not effective and should be resized. If the miss count averages greater than 60 percent, then the cache is really not effective and its objects should be evaluated to see whether they warrant a cache. If the miss count averages above 90 percent, then the objects most likely should not be cached. If the passivation rate per relative time period (I usually choose one minute) is greater than 50 percent of the size of the cache, then the cache is not effective. This depends to a large extent on load, because a cache can be ineffective with a passivation rate that is 1 percent the size of the cache if the cache is not being accessed frequently. The point is to identify how quickly the cache is turning over relative to user load.
In case you need quality webspace to host and run your web applications, try our personal web hosting services.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT During your analysis of connection pools, here are some guidelines to follow: The peak usage should not grow above 80 percent for any significant period of time. Keeping pool usage below 80 percent allows your application to absorb changes in usage patterns. The average usage should be in the range of 50 to 70 percent. If the average usage is below 50 percent, then you want to decrease the size of the pool because you are holding on to too many unused resources; if the average usage is above 70 percent, then you want to increase the size of the pool because changes in usage patterns could significantly impact the performance of your application. No threads should be waiting for connections. Periodic occurrences of five or fewer waiting threads are acceptable, but anything more should trigger a critical alert. If the number of waiting threads grows to the number of connections in the pool, then issue a fatal alert. The database connection pool is saturated and can recover only if the user load diminishes. Caches A few years ago, Marc Fleury, the founder of JBoss, published a blue paper entitled Why I Love EJBs in which he postulated that the entity bean cache delivers a level of magnitude better performance by servicing requests out of memory than accessing a database across the network. He is completely right, and his postulation can be applied to any caching infrastructure: anytime you can service a request directly from memory rather than make a network call, performance will improve. But as with all performance enhancements, caches need to be tuned appropriately. A cache works in the following way: when a request needs an object, it first checks the cache, and only if the object is not available does the request make the network call to obtain the object remotely. In an EJB framework, this caching mechanism is encapsulated for you: you ask the Entity Manager for a bean, and it either serves it from cache or makes a remote call. Caches are a finite size, so to keep the cache current, and hence effective, the cache attempts to keep the most heavily accessed and recent objects in memory. When the cache receives a request for an object not currently in memory, it performs the following steps: 1. Checks for the object in the cache 2. Loads the object by making a remote call (for example, to a database) because the object is not in the cache 3. Runs an algorithm against the cache (usually a least recently used algorithm) to select an object to remove from the cache to make room for the new object 4. Removes the selected object from the cache (depending on your persistence scheme this may require a write back out to the database) 5. Adds the new object to the cache 6. Returns a reference to the object to the caller
We recommend you use shared web hosting services, because many users agree that it is cheap, reliable and customer-satisfying webhost.

282 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Connection Pools To communicate with a database or other external resource, an application needs to obtain a connection to that resource. When communicating with databases, applications use JDBC connections, and when communicating with other resources, applications use either a JCA connection or a proprietary connection. Regardless of the type of connection, creating a connection is usually an expensive operation, so rather than creating the connection every time a request needs one, application servers implement connection pools that create connections ahead of time and make them available to any request that needs one. Requests obtain a connection from a connection pool, use it, and return the connection back to the connection pool when finished. A connection pool greatly improves the performance of applications by removing the connection creation time, but if the connection pool is empty, it can represent a bottleneck in the request call stack. In some cases, a request can wait for a connection to be returned to a connection pool longer than it would take to create another connection, so it s important to accurately assess the health of connection pools. Two primary metrics used to analyze the performance of a connection pool are as follows: Connection pool utilization Execute threads waiting for a connection These metrics are somewhat analogous to the thread pool analysis of utilization and queue depth: what is the percentage of connections in use and are any threads (requests) waiting for a connection? Figure 10-8 shows a healthy JDBC connection pool. Figure 10-8. A healthy connection pool The performance of the connection pool in Figure 10-8 is what we all strive for: Peak usage at approximately 70 percent Average usage between 50 and 70 percent No execute threads waiting for a connection
Go visit our java server pages services for a reliable, lowcost webhost to satisfy all your needs.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT enough load to use all those threads and see if the environment becomes saturated; this would yield a far more conclusive recommendation. Figure 10-7 shows a thread pool under severe distress. Figure 10-7. This thread pool is under any severe duress. It has 10 or fewer idle threads, and the number of pending requests grows to above 100 several times during the test. The performance of the thread pool in Figure 10-7 was so bad that it broke my analysis software (that is, my homegrown analysis software, not my company s software), as some of the pending request spikes grew above 100. In this case, you need to first determine whether the system can support additional threads in other words, is the system already saturated, or can you add additional threads without saturating it? If the system is saturated, then the environment needs additional CPUs or physical machines. But if the system is not saturated, then the size of the thread pool should be increased. Here are some guidelines to follow when you analyze thread pools: The thread pool usage should not grow above 80 percent for any significant percentage of time. There should not be any pending requests. Periodic occurrences of five or fewer waiting threads is acceptable, but anything more should trigger a critical alert. (Setting a threshold of five requests avoids catching in-flight requests that are added to a request queue but removed almost instantly by a live thread, meaning that the snapshot is taken between the time the request is added to the queue and a thread pulls it off of the queue.) If the number of waiting pending requests grows to the size of the thread pool, then issue a fatal alert. At this point, the thread pool is saturated and can recover only if the user load diminishes. Compare the number of open sockets to the size of the thread pool. If there is a huge discrepancy, such as twice as many open sockets as threads, then advise the user that the size of the thread pool may need to be increased. Review the behavior of the request throughput against load (open sockets). If there is a point where the load increases but the throughput decreases, then chances are your thread pools are saturated.
If you are in need for chaep and reliable webhost to host your website, our recommendation is http web server services.

280 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT many system resources, and depending on your operating system and threading library, this may be true. For example, in earlier versions of Linux, each thread ran in its own process, and the operating system limited the maximum number of processes (usually to 256). With other operating systems (such as Windows, Solaris, and AIX), and with an alternate threading library in Linux, all threads run under the umbrella of a single process. So while system resources are required to support multiple threads, dormant threads do not consume CPU time and thus their impact on the system is relatively minimal. The much greater potential danger in maintaining too many threads is that they could all be in use at once. Consider an environment that can optimally support 100 threads but maintains a thread pool with 200 threads. If 200 threads are in use, then the CPU will become saturated because it has to switch the CPU context between all 200 threads. It is far more efficient to cause requests to wait in a request queue while earlier requests are processed optimally, rather than to force too many requests into a system that cannot support them. The second characteristic, queue depth (sometimes simply referred to as pending requests), reports the number of requests waiting in the queue to be processed. The queue depth will grow if requests are received and threads are not available to process them. Finally, the request throughput is a measure of requests processed over a period of time, such as requests processed per second. In essence, the throughput tracks the capabilities of your application at the current load. Figure 10-6 shows a thread pool that is not under duress. Figure 10-6. This thread pool is not under duress. It has almost 100 idle threads at all times with no pending requests while supporting 10 20 simultaneous open connections. Figure 10-6 displays the following information: Idle Threads: The number of threads in the thread pool that are available to process requests Queue Length: The queue depth, or number of pending requests Open Sockets: The current number of open sockets, or simultaneous requests The thread pool in Figure 10-6 is highly underutilized, and if the sample period is representative of average user behavior, then the thread pool could be reduced in size to limit the impact on system resources. But of course you would want to test this environment with
Searching for affordable and proven webhost to host and run your servlet applications? Go to Linux Web Hosting services and you will find it.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT utilization. If the heap had over 1GB of memory available, then how could the heap report an OutOfMemoryError? The answer was that although the error message appeared to be from the heap, it was actually generated by an event in the permanent space. The permanent space was full (from loading application classes), and as a new class was requested, there was no room for it, so the JVM threw an OutOfMemoryError and crashed. In the end, we upgraded the system to a newer JVM and subsequently enabled class unloading to solve the problem. In summary, analyzing the performance of process memory can help you identify operating system constraints, process memory contention, and paging, and better understand the impact of the JVM s permanent generation space. Application Server In a performance analysis report, the platform is separated into two parts: the environment and the application server. The application server has its own category because it has so many moving points to tune. Specifically, the performance analysis report examines these components, which we ll cover in the sections that follow: Thread pools Connection pools Caches Component pools Message servers Transactions Choose the components that are relevant in your environment. For example, if you are not using entity beans and do not have any other caching infrastructure in place, then omit that section. The amount of space dedicated to any given topic will be wholly dependent on your environment; focus on what is important to your application. Thread Pools When an application server receives a request, either via the Web or through RMI, it accepts the request and places it in an execution queue. Each execution queue maintains a pool of execution threads. When a request is placed in the queue, if a thread is available, then the thread processes the request, but if a thread is not available, then the request is forced to wait for a thread to become available. Analysis of the performance of a thread pool involves the following characteristics: Thread pool utilization Queue depth Request throughput Regarding the first point, thread pool utilization, you need to carefully choose thread pool sizes, as there is a balance between system resources, request processing, and CPU saturation. The most common complaint I hear about sizing a thread pool too large is that it consumes too
If you are looking for affordable and reliable webhost to host and run your business application visit our ftp web hosting services.

278 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Note The difference between elapsed time and CPU time may initially be confusing. Here is an example that highlights the difference: consider a method that checks a queue and then sleeps for 30 seconds. In an elapsed recording, this method would report that it spent 30.01 seconds to complete, while in the CPU recording, it would report only the 0.01 second, because it did not have the CPU while sleeping. Both metrics are interesting to observe: the elapsed time reports the perceived run time for a method (if the tested code is not a background process, then the reported time is the amount of time that a user had to wait for this functionality to complete), whereas the CPU time reports the amount of time that a method had the CPU. In summary, here are the steps I recommend following when evaluating the health of an environment s CPUs: 1. Observe the CPU utilization during the recording. Check whether the CPU is climbing normally or spiking. 2. Determine whether CPU spikes (if any) are associated with garbage collections. 3. If CPU spikes are not associated with garbage collection, then identify the methods and lines of code that were running during the spike. Process Memory Utilization The operating system process memory for the JVM process includes the heap as well as the permanent generation memory. The permanent generation memory is used for loading things that do not reside in the heap, such as the contents of a .classfile that is used when constructing class instances on the heap. Examining the process memory is important to observe the following two items: Operating system memory constraints Permanent memory anomalies With regard to the first point, the size of your JVM process will always be larger than the size of your heap due to the JVM permanent objects that it needs to manage your Java applications. Some operating systems restrict the amount of memory that a single process can occupy, so you need to be aware of how much memory your Java process is using. If the process runs out of memory, then it can crash your entire environment. Furthermore, you need to ensure that your JVM heap is never running in a swapped capacity, meaning that the heap is running in virtual memory because not enough physical memory is available to support it. Swapping memory to disk is almost always a bad idea (from a performance perspective), but doing so in an enterprise environment is even worse. In reference to the second point, it is important to observe the behavior of physical memory in conjunction with verbose garbage collection logs to understand the behavior of the permanent generation. The primary use of the permanent generation is to hold descriptions of classes that are used to create class instances on the heap. I mentioned in Chapter 7 an incident where my attention to process memory utilization identified a puzzling problem: the application reported that it was out of memory, but the heap utilization was at or below 50 percent
If you are looking for affordable and reliable webhost to host and run your business application visit our ftp web hosting services.

CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT In addition, the -XX:+PrintGCDetails option provides details about the changes in heap partitions, and the -XX:+PrintGCTimeStamps option prints the time of garbage collection occurrences relative to the start of the JVM. With these options, you can generate a log file from which you can extract the garbage collection rate, time, and impact. For more information, refer back to Chapter 7 and then read through Sun s Tuning Garbage Collection with the 5.0 Java Virtual Machine document, which you can find at the following URL: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html CPU Utilization CPU utilization is one of the best measures of your application s impact on its underlying hardware. What you hope to observe is a relationship between application load and CPU utilization: the CPU steadily increases as the load increases, and the CPU decreases as the load decreases. If your physical machine can support the load that it is subjected to, then you should never see the CPU utilization grow over 80 percent, but if the CPU is consistently over 85 or 90 percent, one of the following two conditions is true: Your application is too CPU intensive and needs to be refactored. Your environment simply cannot support the load it is being subjected to. The easy solution to this condition is to add additional CPUs or new machines to your environment, but this is expensive, in terms of both hardware costs and software licensing costs. A more time-consuming option, but one that is better in the long term, is to analyze your application components inside a code profiler and refactor the code sections that are performing poorly. However, if you observe periodic CPU spikes for example, a machine that averages 30 percent CPU utilization unexpectedly spikes to 90 to 100 percent utilization, and returns back to 30 percent utilization then this behavior can be categorized as either an effect of garbage collection or an application anomaly. Whenever a stop-the-world garbage collection occurs, the CPU spikes significantly, usually pinning itself at 100 percent until the garbage collection completes. Therefore, whenever you observe a CPU spike, check for a correlation with an occurrence of a major garbage collection. If you find no correlation between a CPU spike and an occurrence of a major garbage collections, and the CPU utilization is associated with the Java application server process (by looking at the CPU utilization of the application server s java process), then it is possible that you have detected a problematic piece of application code. In this situation, the strategy is to identify the requests that were running during the CPU spike (if you do not have a tool to help you identify these requests, you can find the information by parsing access logs) and replay those requests against your application running in a code profiler. Your code profiler should allow you to profile your application using elapsed time (including blocked threads and waits) or CPU time. To detect a method or application subgraph that is abusing the CPU, set this configuration option to CPU time and find the top offending methods and lines of code that occurred during each request candidate.
Please visit Domain Name Hosting services for high quality webhost to host and run your jsp applications.

276 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT Figure 10-5. Garbage collection rates in the new generation and in the old generation Figure 10-5 shows that the majority of garbage collections occurred in the young generation, with at most one per minute occurring in the old generation. New, or young, generation garbage collections are referred to as minor collections and occur against a running heap; old generation garbage collections are referred to as major collections and require the heap to be frozen in order to run (these are also called stop-the-world garbage collections). While major garbage collections occur relatively infrequently in relation to minor collections, it is still a point of concern that they are occurring as frequently as once per minute. For a large heap (1GB 2GB or larger), a major garbage collection can take several seconds to run, so your heap should be configured to minimize these occurrences. In a well-tuned heap and a solid application, major garbage collections should occur at most a couple times per day; in a well-tuned heap for an average application, you can still reduce this rate to once or twice per hour. The second graph in Figure 10-4 displays the overhead that the garbage collector is inflicting on the system. An average overhead of approximately 15 percent is too high for an average environment and indicates the heap needs to be tuned. Chapter 7 discussed the strategies employed to tune both the Sun and IBM JVM heaps. Aside from using a monitoring tool to assess the health of garbage collection, you can gain valuable information at about a 5 percent overhead by using the JVM s -verbose:gc option.
You need excellent and relaible webhost company to host your web applications? Then pay a visit to Inexpensive Web Hosting services.