Generally speaking, you start with analysis. Where is your program spending the most time? There are tons of profilers out there, a quick search should find them (and tutorials on how to use them).
Once you know WHERE your program is spending its time, you then look at the places you can get the most bang for your buck. You may want to completely re-write your sort algorithm, but if your program is only spending 0.1% of the time there, you won't gain much.
If if your db select statement is taking 30% of the time, then it is possible a new index could speed things up dramatically.
Author and all-around good cowpoke
Joined: Mar 22, 2000
Resist the urge to try various "optimizations" instead of doing the analysis as recommended by Fred.
Try a google search for "premature optimization is the root of all evil" - a famous programmer aphorism - as an amusing diversion.
it is important to take the type of application into consideration. So that performance solution can be more effective. For example, if you are only writing a blog in Java, it will be mostly read. Maybe utilizing caching will speed up performance
• Before going to start the performance improvement analysis you should have the SLA for each page, it means the expected responses time from the customer or end user.
• Execute performance test and get the base line results, before adding any performance optimizations.
• Use http watch plugin for getting total execution time for each page rendering.
• Identify the hotspots at method level, for this we have to enable the loggers to get the each method execution time.
• Identify the SQLs and checks all the SQLs having the proper indexing at DB level.
• Check if there were any optimization is possible in SQLs.
• Check the code level if any unnecessary query execution is happened and try to make it as less.
• Profiling the application will be giving more data points for adding optimizations.
• Using yslow plugin for getting more information for js, css and image related optimizations.
There is no way to completely answer this question in a few words or paragraphs. Performance tuning is one of the more complicated tasks, especially if you have limited expertise. When I have to deal with the performance tuning I am following the systematic approach.
First, find the parts of the application that require improvement, whether they’ve been discovered during the development cycle, functional testing or reported by the application users in production. No reason to take on everything as you will complete nothing.
Depending on the system - the real issue can lay in hardware, network, system architecture, custom code, or combination of things, etc.
Without proper approach - you can spend weeks, months without success. And try to add heavy user load scenarios to the mix and this will multiply the complexity.
Second - define what tools you will use to identify the issue. You can decide to analyze JVM first, or use known java profilers, or use java monitoring and analytical tools.
I personally like to have a big picture first and then be able to drilldown to the lowest possible level. There are a few tools available on the market to help you with that. I recently used Discovered Byte analyzer with good results (and it is free). You can get it from http://discoveredbyte.com. What I like about it? It will highlight and give you quick view of the system or specific issue that you are dealing with in pre-analyzed report. I see it as big picture of the issue(s).
When I have that - If I see that server utilization is constantly maxing, then it is limitation on the hardware side (unless you have memory leaks or inefficient code that eats up CPU. Unfortunately you can’t check memory leaks with the Discovered Byte analyzer, but you can see CPU usage by heavy methods, and for me it is very important.)
If I see heavy methods or pages - I drill down to the method. I like to use filters and control level of the execution to display heaviest methods that contributed to the bad performance results.
The lowest hanging fruit is bad queries - you can view them as well, but in reality - you are lucky if it is just SQL issue. I recently dealt with repeated SQLs - single query was executed in just a few milliseconds, but was ran many thousands times from the single method! (That was fun to catch?)
Third - once you have the data you can make a decision on how to fix it. HW or custom code – the easiest ones; architectural flows or vendor code usually take longer time to address.