260 CHAPTER 10 JAVA EE PERFORMANCE ASSESSMENT (Web hosting account)
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.