Softwares are a man’s best friends but when they are slow and sluggish they can be the worst woe. These softwares are designed to decrease human effort and increase productivity. However, if they don’t perform optimally the purpose of these softwares is lost and the manual effort is increased. In fact responsiveness and scalability are considered a make or break quality for a software. Poor performance costs the software industry a lot in lost revenue,
decreased productivity, increased development, development costs and customer relation deterioration.

Irrespective of the source of the software mode, it must be fixed immediately. Often when such an issue occurs the software goes into crisis mode. Thus, here it is vital to redesign the software completely or to fix the performance issues to make it ideal when it comes to performance.

Sherlock Holmes was a true genius in solving mysteries and he said that you can’t solve a mystery without having the right information and facts because then you start building your own facts and steer away from the problem. This is also the case when we talk about a software, without the right data and information solving a problem is very difficult. The right information will help isolate the problem and reach the right solution.

With limited time for tuning and the extend of improvement, the software often runs into problems, what is needed is to spend on these rather than redundant things that don’t drive any results.

First and foremost, you need to figure out where you need to be. Often when software is developed they have vague performance objectives, which don’t tell you how much? How? Or what? Of the things. It is best to have quantifiable, strict performance objectives. In fact, it is best to have performance objectives at several levels likes resources, response time, output etc. to cover all parameters and to avoid any further issues. Also what has to be kept in mind is that performance objectives have to be over the products lifetime, say the output should double in the next two years, or the response time should be reduced over the next couple of years.

Then you also need to determine where you are now. Typically, you need to check which parts of the software are giving you problems and how you can tackle these problems at the root. Also checking the workloads that give problems can help in reaching a reasonable solution.

We have found that starting with an understanding and assessment of the software architecture offers better opportunities for achieving performance and scalability objectives. We have found that it is best to understand the software’s purpose, architecture, and processing steps to:
• determine if the architecture can support scalability goals,
• determine if problems can be fixed with tuning and which parts to tune (before spending months trying to no avail),
• to project the scalability, throughput and response time with the tuning changes.
• to determine whether MIPS reduction requires re-design or if tuning is sufficient [Williams and Smith 2002a].
However, one crucial part is also to check whether the objectives can be achieved or not. It is ideal that before tuning you take stock of where you are right now and where do you want to be, if this difference is not large tuning might help and you can also use tuning. You can also achieve your performance objectives updating the code by tuning operating system parameters, network configuration, file placements, and so on. If not, you’ll need to tune the software.

After identifying the the solutions and the problems, you need to rank these on the basis of basis and then start tackling the solutions on the basis of the payoff. After making all the changes it is ideal to check the cost and benefit, by a cost benefit analysis to check if the improvement overcomes the cost. This data will be helpful in the future when such problems arise with the same or a different software.