CHAPTER 14 SOLVING COMMON JAVA EE PERFORMANCE (Free web host)
CHAPTER 14 SOLVING COMMON JAVA EE PERFORMANCE PROBLEMS When page- or request-scoped variables maintain references to objects, they are automatically cleaned up before the request completes. Likewise, if session-scoped variables maintain references to objects, they are automatically cleaned up when your application explicitly invalidates the session or when the session time-out is exceeded. Probably the greatest number of false positives in memory leak detection that I see are leaky sessions. A leaky session does not leak anything at all; it consumes memory, resembling a memory leak, but its memory is eventually reclaimed. If the application server is about to run out of memory, the best strategy to determine whether you have a memory leak or a poorly managed session is to stop all input to this application server instance, wait for the sessions to time out, and then see if memory is reclaimed. Obviously, this procedure is not possible in production, but it offers a surefire way to test in production staging, with your load tester, if you suspect that you may have large sessions rather than a memory leak. In general, if you have excessively large sessions, the true resolution is to refactor your application to reduce session memory overhead. The following two workaround solutions can minimize the impact of excessively large sessions: Increase the heap size to support your sessions. Decrease the session time-out to invalidate sessions more quickly. A larger heap will spend more time in garbage collection, which is not an ideal situation, but a better one than an OutOfMemoryError. Increase the size of your heap to be able to support your sessions for the duration of your time-out value; this means that you need enough memory to hold all active user sessions as well as all sessions for users who abandon your Web site within the session time-out interval. If the business rules permit, decreasing the session time-out will cause session data to time out earlier and lessen the impact on the heap memory it is occupying. In summary, here are the steps to perform, prioritized from most desirable to least desirable: Refactor your application to store the minimum about of information that is necessary in session-scoped variables. Encourage your users to log out of your application and explicitly invalidate sessions when users log out. Decrease your session time-out to force memory to be reclaimed sooner. Increase your heap size. However, unwanted object references maintained from application-scoped variables, static variables, and long-lived classes are, in fact, memory leaks that need to be analyzed in a memory profiler. Permanent Space Anomalies The purpose of the permanent space in the JVM process memory is typically misunderstood. The heap itself only contains class instances, but before the JVM can create an instance of a class on the heap, it must load the class bytecode (.class file) into the process memory. It can then use that class bytecode to create an instance of the object in the heap. The space in the process memory that the JVM uses to store the bytecode versions of classes is the permanent space. Figure 14-6 illustrates the relationship between the permanent space and the heap: it exists inside the JVM process memory but is not part of the heap itself.
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check mysql web server services.