294 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT (Web design portfolio)
294 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT A slow method. If the problem is not the result of an external call or the sheer number of calls to a method, then the ultimate issue may simply be the method itself. When this occurs, the answer is to take the code off-line and analyze it in a code profiler to determine why it is slow. An environmental issue, such as a saturated thread pool or a major garbage collection. Diagnosing Implicit Problems When diagnosing application issues, you may inadvertently discover environmental problems. The manifestations of these problems may be initially confusing because slow response times at these points should not be possible, but once you understand that they are wait points, it all becomes clear. The sections that follow detail common interpretations of implicit problems discovered through application call tree analysis. Thread Pool Pending Request During the course of request analysis, you may see a request waiting at the application server s embedded Web server. This is characterized by a significant amount of time being spent in the GET /webapp/myaction.do node (or whatever the URL happens to be), which is the node that executes just prior to the servlet s process(), doGet(), or doPost() method. In theory this is impossible, because the after the Web server receives a request, it should immediately invoke the appropriate servlet, but it makes sense as soon as you realize that the request handling process places the request in a queue and it is subsequently picked up by an execute thread for processing. Any exclusive time spent in this node identifies the amount of time a request is spending in a request queue waiting for an execution thread. On a related note, if you separate your environment into a distinct static Web tier and a dynamic Web tier by placing a Web server such as Apache or Microsoft IIS in front of your application, you can learn how much time the request spends in the Web server before being passed to the application server by looking at that node. Different monitoring tools have different solutions for they type of integration, but the tool I use, PerformaSure, has a specific Web server plug-in that records that time. Typically this pass-through is quick, so a large exclusive time in this node may be an indication that the Web server thread pool is backing up. JDBC Connection Pool Although you have explicit JDBC connection pool monitoring and rules to determine when all of the connections in a connection pool are in use, you can identify the same problem implicitly and learn about the requests being affected by looking at bytecode instrumentation. During the course of your application processing a request, if your application needs a database connection, it obtains that connection from the connection pool when your code calls DataSource.getConnection(). The getConnection() method is available through bytecode instrumentation, and if a connection is available in the connection pool, then it should be returned almost instantaneously. But if the request spends any significant amount of time in the getConnection() method, the connection pool does not have any available connections and is forced to wait for an available connection.
From our experience, we are can tell you that you can find a reliable and cheap webhost service at Java Web Hosting services.