OFF when required in your day to day production support.It is important to realize that your Java EE middleware specifications may be adequate but may lack proper tuning. Most Java EE containers available today provide you with multiple tuning opportunities depending on your applications and business processes needs.Failure to implement proper tuning and best practices can put your Java EE container in a non-optimal state. I highly recommend that you review and implement proper Java EE middleware vendor recommendations when applicable.Find below a high-level view and sample check list of what to look for.
Lack of monitoring is not actually "causing" performance problems, but it can prevent you from understanding the Java EE platform capacity and health situation. Eventually, the environment can reach a break point, which may expose several gaps and problems (JVM memory leak, etc.). From my experience, it is much harder to stabilize an environment after months or years of operation as opposed to having proper monitoring, tools, and processes implemented from day one.That being said, it is never too late to improve an existing environment. Monitoring can be implemented fairly easily. My recommendations follow.

Review your current Java EE environment monitoring capabilities and identify improvement opportunities.

Your monitoring solution should cover the end-to-end environment as much as possible; including proactive alerts.

The monitoring solution should be aligned with your capacity planning process discussed in our first section.

Another common source of performance problems is hardware saturation. This problem is often observed when too many Java EE middleware environments along with its JVM processes are deployed on existing hardware. Too many JVM processes vs. availability of physical CPU cores can be a real problem killing your application performance. Again, your capacity planning process should also take care of hardware capacity as your client business is growing.My primary recommendation is to look at hardware virtualization. Such an approach is quite common these days and has quite a few benefits such as reduced physical servers, data center size, dedicated physical resources per virtual host, fast implementation, and reduced costs for your client. Dedicated physical resources per virtual host is quite important since the last thing you want is one Java EE container bringing down all others due to excessive CPU utilization.
Our last source of performance problems is the network. Major network problems can happen from time to time such as router, switch, and DNS server failures. However, the more common problems observed are typically due to regular or intermittent latency when working on a highly distributed IT environment. The diagram below highlights an example of network latency gaps between two geographic regions of a Weblogic cluster communicating with an Oracle database server located in one geographic region only. Intermittent or regular latency problems can definitely trigger some major performance problems and affect your Java EE application in different ways.

Applications using database queries with large datasets are fully exposed to network latency due to high number of fetch iterations (back and forward across network).

Applications dealing with large data payloads (such as large XML data) from external systems are also exposed to network latency that can trigger intermittent high-response time when sending and receiving responses.

Java EE container replication process (clustering) can be affected and put at risk its fail-over capabilities (e.g., multicast or unicast packet losses).

Tuning strategies such as JDBC row data "prefetch", XML data compression, and data caching can help mitigate network latency. But such latency problems should be reviewed closely when first designing the network topology of a new IT environment.I hope this article has helped you understand some of the common performance problems and pressure points you can face when developing and supporting Java EE production systems. Since each IT environment is unique, I do not expect that everybody will face the exact same problems. As such, I invite you to post your comments and share your views on the subject.#1 - Lack of proper capacity planning#2 - Inadequate Java EE middleware environment specifications#3 - Excessive Java VM garbage collections#4 - Too many or poor integration with external systems#5 - Lack of proper database SQL tuning & capacity planning#6 - Application specific performance problems#7 - Java EE middleware tuning problems#8 - Insufficient proactive monitoring#9 - Saturated hardware on common infrastructure#10 - Network latency problems

Performance Engineering -Sreenivasulu kota