Thursday, May 24, 2007

J2EE Application Performance Tuning and Optimization

When an application is deployed into the production environment, there are many factors contribute to the ultimate application performance & throughput, not only from application iteself, but types of hardward, settings and configurations of os and servers( web, application & database) and even the way of network setup also play a part.

As there are many places may degrade the performace, approches and solutions will be different and various. Maintaining a list of articles and papers about these approches and soutions will be very helpful & useful in our team and I would like to put some effort to maintain a such list of articles available in the internet regarding the application side(E.g programming practise, application server configurations, technology usage and etc).

Performance tuning is as much as it is a science, team work will be more productive and enjoyable than one man show. If you are the people like me and would like to put some effort into this, let me know and maybe in future we can co-author a paper or a course ( English/Chinese) based on our experience and knowledge gained. :)

In the meantime, i would like to share some of my own experience in the performance tuning and optimization.

In the reality, when expecting application performance & throughput is not met, no party in the project would like to admit the issues or problems are from them since people don't like changes and project deadline is around the corner. In the end, the deadline is extened and peoples from different team (application, infrastructure, database) have to sit together to look into the case.

No matter which team are responsible for it, the most important thing is to find out where & what the bottlenecks are degrading the performance. Bare in mind that there maybe more than one bottleneck exist and no point to complain other people. There are some verifications we can do to find out them one by one until the output meets the expectation.

To verify whethere the network is the cause, we can try to ping or ftp an big file to the target machine to get to know the network speed. If the speed is very slow, it may be one of bottleneck degrading the application, we can inform the infrastrucre team to review their network routing strategy.

To verfiy whethere servers are running or responding slowly, there are a few things we need to look out. We need to know the hardward type, os configuration and server installation version. Especially in the staging environment, one machine may be shared by multiple teams and applcaitons and people can cap the cpu & memeory resource for certain process such as the database server, application server and even your deployed applicaton without knowing it. People can tell you that the machine running the application or servers is a very fast and even with dual processor, but it doesnot mean you are having full power of that machine.

Other than the OS configurations, you also need to know the installation version of server (database, application) and whether they has been installed and setup with recommened parameters and models.

For the application, usually the performace issues are from inefficient business logic, bad sql statement (E.g not using prepared statement & execute batch and commit too frequently, etc.) and db connection handling (connection pooling, leaking, jdbc driver). Usually, a code review will be very helpful to spot those problems. For the sql statement, it is best to consult with DBA to tune the sql (such as truncating a table VS deleting all records). To spot whether there is a db connection leaking, run the "netstat" in the command line and verfiy if there are any outstanding db connection ports opening after db works are done. If the problem still can not be identified, you can use tools like application profiler to spot the bottleneck from certain method or function of the application and narrow down until you find the problem.

No comments:

´