DOCX

Affect the performance of Java EE ten big problem

By Jamie Morgan,2015-04-05 23:44
16 views 0
Affect the performance of Java EE ten big problem

    Affect the performance of Java EE ten big

    problem

    The writer is a senior has 10 years of experience in the system architect, his main professional field is a Java EE technology, middleware, and JVM.He is also in the field of performance optimization and promotion has very insightful, he will share with you the below 10 common Java EE performance problems.

    1. The lack of correct capacity planning

    Capacity planning is a comprehensive standard and the development process, predict IT environment capacity of current and future needs.Formulate reasonable capacity planning will not only ensure and track the current production capacity and stability of IT, IT will also ensure that the new project with minimum risk of deployment to the existing production environment.Hardware, middleware, the JVM, adjustment should be ready before the project deployment.

    2. Lack of Java EE middleware environment specification

    "No rules, no fangyuan".The second common reason is that the Java EE middleware or infrastructure.In the initial project, not formulate reasonable specifications on the new platform, cause the system stability.It would increase the cost of the customer, so take the time to formulate reasonable Java EE middleware environment specification is a must.This work should be combined with the iterative initial capacity planning.

    3. The Java virtual machine (excessive garbage collection

    You for "Java. Lang. OutOfMemoryError" this error message is not very familiar with?Due to the excess consumption of the JVM memory space (Java heap, the native heap, etc.) and the exception thrown.

    Garbage collection questions will not necessarily appear as a OOM conditions, excessive garbage collection can understand as a JVM GC thread in a short time due to excessive collection data collection or slightly JVM pause time is very long and performance degradation.There may be several reasons:

    1. Compared with the load and application memory footprint JVM, the Java heap may

    choose is too small.

    2. Use the JVM GC policy is not reasonable.

    3. Application of static or dynamic memory footprint is too big, not suitable for use on a

    32-bit JVM.

    4. The JVM OldGen over time, the leakage is more and more serious, and GC found only

    after several hours or days.

    5. Only the HotSpot JVM PermGen space (VM) or the native heap over time will reveal that

    is a very common problem;OOM error are often observed after a period of time, the

    application of dynamic transfer.

    6. YoungGen and the proportion of OldGen space does not match with your application.

    7. Java heap on 32-bit VM is too big, lead to the native heap overflow, concrete can be

    characterized by OOM try to link a new Java EE applications, create a new Java thread,

    or need to calculate the local memory tasks.

    Advice:

    1. To observe and understand the JVM garbage collection.Start the GC, according to the

    reasonable assessment of health to provide all of the data.

    2. Remember, the related problems of GC not or functional test found in the development, it

    needs to be found in multi-user high load test environment.

    4. With external systems integration too much or too little

    Lead to the worse performance of Java EE the fourth reason is highly distributed system, a typical case is telecom IT environment.In this environment, a middleware (for example, a service bus) rarely do all the work, and "trust" is just to get some business to other parts, such as product quality, customer information and order management, to other Java EE middleware platform or legacy systems, such as supporting a variety of different load type and communication protocol of the mainframe.

    Such external system call means that the client's Java EE application trigger to create or reuse socket links to read and write data from external systems.According to

    the implementation of business process and implementation can be configured to synchronous calls or asynchronous calls.It is important to note that the response time will according to the stability of the external system status change, so through the use of appropriate timeout to protect the Java EE applications and middleware is also very important.

    The following 3 kinds of situation is often appear problem and the place of performance:

    1. Synchronization and subsequently call too much external systems.

    2. In Java EE client application and the links between external system timeout, make the

    loss of data or high value leads to the client thread stuck, resulting in much meera effect.

    3. Timeout, but the program is still normal execution, but don't deal with this strange path

    middleware.

    Finally, it is suggested that more than a negative test, that means "human" to create conditions for such problems, used to test the application and middleware is how to deal with the external system error.

    5. Lack of proper database SQL tuning and capacity planning

    Everyone is likely to be the a surprise: the database problems.Most Java EE enterprise system is dependent on the relational database processing complex business processes.A solid solid database environment can ensure the IT environment has the growth of the scale, to support the increasingly expanding business.

    In practice, and the performance of the database related problems are common.Because most database transaction processing is performed by the JDBC data sources (including the relationship between the persistence API, Hibernate, for example).But first will show the thread block performance.

    Here is my job in ten years, often appear about database problems for the Oracle database (for example) :

    1. Isolated, long running SQL.Main show is thread block, SQL is optimized, the lack of the

    index, the best execution plan, return to a large number of data sets, and so on.

    2. Data table or row-level locking.When submit a double stage transaction model (for

    example, the infamous Oracle suspicious transactions).Java EE container could leave

    some pending transactions waiting for the final committed or rolled back, leaving the data

    lock can trigger performance problems, until finally the lock has been removed.Such as

    power outages or server middleware collapse is likely to cause these things happen. 3. The lack of a reasonable standard database management tools.Like the inside of the

    Oracle REDO logs, database data files, etc.Not rotating disk space is insufficient, log files,

    and will trigger the larger performance issues and power cuts.

    Advice:

    1. Reasonable capacity planning, including load and performance testing are indispensable,

    optimize the environment of data and found the problem in time.

    2. If the Oracle database is used to ensure the DBA team regularly review who runs AWR

    reports, especially in the fluctuation of the associated events and root cause analysis

    process.

    3. Use the JVM thread storage and who runs AWR report found out the cause of the slow

    SQL or use monitoring tools to do it.

    4. Strengthen the aspects of the database environment "operation" (disk space, data files and

    redo log, table space, etc.) with appropriate monitoring and alarm.If you don't do this, will

    let the client IT environment appears more power and spend a lot of time for fault repair. 6. Specific application performance problems

    The following concerns that serious Java EE application problems.About a

    specific application performance problems, summarizes the following several points: 1. Thread-safe code

    2. Communication API lack timeouts

    3. The I/O, JDBC or relational API resource management issues

    4. A lack of proper data cache

    5. Data cache too much

    6. Excessive logging

    7. Java EE middleware tuning problem

    General Java EE middleware has had enough schooling, but lack the necessary

    optimization.Most Java EE container can have a variety of solutions for your

    application and business process to choose from.

    If there is no proper adjustment and practice, so the Java EE container may be in

    a passive state.

    Below is a list view and check the sample:

    8. Active monitoring

    Lack of monitoring, will not bring real performance problems, but it can affect your understanding of the Java EE platform performance and health.Eventually, this environment can achieve a break point, it may reveal some defects and problems (JVM memory leaks, etc.).

    In my experience, if not monitored at the beginning, but to run for a few months or a few years later, stability of the platform will be discounted.

    That is to say, to improve the existing environment will never be late.Here are some Suggestions:

    1. Review of the existing Java EE environment monitoring ability and find a place to need

    to improve.

    2. Should as far as possible to cover the entire environment monitoring solution.

    3. Monitoring solution should comply with the capacity planning process.

    9. Public infrastructure hardware saturated

    The problem often have too much Java EE middleware environment as the JVM process is deployed to see above the existing hardware.Too much of the JVM process for limited physical CPU core is a real killer application performance.In addition, as the growth of the client business, hardware side also need to consider again.

    The network latency

    The final impact performance problem is the network, network problem happens from time to time, such as routers, switches, and DNS server failure.More common is in a highly dispersed on a regular basis or intermittent delay in the IT environment.Example in the picture below is a located in the same area of Weblogic cluster communication and the delay between the Oracle database server.

    Intermittent or regular delays will trigger some important performance problems, affects the Java EE application in different ways.

    1. Because a lot of the fetch iteration (network incoming and outgoing), involves the use of

    a large data set of data query problem will be very influenced by network latency

    2. Big data load application in the treatment of the external system (such as XML data) will

    be affected by network latency and can produce huge when sending and receiving the

    response the response of the interval.

    3. Java EE container replication process (cluster) would also be affected, and will let the

    failover (such as multicast or unicast packet loss in risk.

    JDBC row data prefetch ", XML data compression and data caching can reduce the network latency.When designing a new network topology, should carefully check the issue of network latency.

    Hope this article can help you understand some of the common performance problems and pressure point, every IT environment is unique, so the problems mentioned in the article do not necessarily is you encounter, you can bring out the problem you encountered and everyone share once!

Report this document

For any questions or suggestions please email
cust-service@docsford.com