Java EE minimization of resource pressure test rules

I saw someone talk about the performance of Java EE tuning, although this piece is not their own expertise, but the pig raised more, can not help but jump out to say a few words.

Although almost every book on performance tuning begins, do not need to do the tuning, but I personally think that all systems before the line, should do a basic pressure test and related performance problems to detect, but under the resource pressure, many projects can not do formal stress testing, Until there is a problem on the system line, just back to find the reason. and formal stress testing, often because of the need to strictly simulate the production environment, the need to spend a lot of resources, all kinds of experts to solve the problem, is not so easy to do it down.

And the characteristics of the Java EE application is to avoid the traditional problems with complexity, so any one of the Java-EE deployment, compared to the structure of PHP is more complex. Once the system has a performance problem, must be in the program, database, Application Server, JVM, operating system in a few blocks across the consideration, according to the actual problem, the cause of the problem may be extremely complex. We can imagine a project, never do UT do not do it, do only once uat, and then directly submitted to the user after the online, fix the difficulty and cost of error.

Often see some tuning of the final solution, you can be sure that almost 80% of the above are some low-level error caused by the program, the remaining 20% although it may be with hardware, OS parameter adjustment and so on, but it is a big piece, in the final analysis is the problem of the program. And when we look back at these mistakes, it's amazing to see that most of them are low-level bugs.

I advocate using minimal resources to do a stress test that eliminates most of the obvious application problems. Minimum resource means to perform stress testing and performance problem detection in a PC environment using the minimum resource state that can be run by the application. The advantages of this approach are as follows.

1. The environment is easy to build, especially without the need to consider large hardware and network conditions, and so on, but also to avoid the developer may not be familiar with UNIX and specific application server issues

2. Do not need a special database, operating system and application server experts to cooperate with the developer can complete.

3. No special dependencies on OS and application servers, JVM monitoring tools are required. Choose the one you are most familiar with.

4. Developers who are familiar with this process will be more experienced and more likely to solve problems when transferred to the formal production environment.

Make a brief introduction to the test process.

Tool Preparation:

Thanks to the development of open source technology, most of the tools are available for free and easy to use.

1. JVM Monitoring: Analysis of the running state of the JVM, using the characteristic output logs of the JVM itself, combined with HP's JMeter profile. You can also use JRockit's own graphical tool mession control.

Familiar with what to use, the simpler the better, the main purpose is to observe the memory heap changes, thread resource changes, GC, and so on.

2. Database monitoring tools: familiar with the database use of the database itself, unfamiliar with the use of Third-party tools, the main purpose is to observe the database lock, connection number information, for DB2 I prefer to use Quest Central. Oracle can already use an OEM or its own data dictionary.

3. Application Server monitoring: The main purpose is to record the invocation of the method and execution time, to find out frequently called methods and execution time is too long method. The use of Jprobe and jprofile can be easily done. If you are using an application server that is biased, you can switch to an application server that supports this detection tool. The main purpose is to find the problem anyway.

4. SQL execution monitoring: Trace to find the execution time is too long SQL. I like to use P6spy.

5. Pressure tool: Jmeter+badboy, conditional can use LoadRunner, and LoadRunner approximate also has a free open source product. Other Web applications can also be done using FF extensions such as selenium. Microsoft Vs is also good, anyway is what simple with what.

6. Record form: Record and compare the changes to the problem and resource configuration.

I found that some people do stress testing, only using pressure tools to run, not using various Proile tools to track applications and database use, coupled with the lack of experience, the results are measured by guessing.