Performance, though this concern exists in an application development lifecycle since day one, it comes into picture only when the first performance problem is reported, mostly in production environment. Application is ready; unit testing, integration testing and functional testing rounds are complete. And now its time for some load/performance testing cycles. In just a few hours, the performance testing team shouts ‘the page is taking ages to load’, ‘I can click on a button, go get a coffee, finish it off, and the application is still cooking something behind and not presenting me’, and so on. Fuming developers and managers go back and do post mortem to find the problems which cannot be fixed with tag ‘quick fix’. Some demand design change, others require different technology, while one of the architect says – who the hell accepted this performance requirement. But the bottom line is – application is not accepted because it is not performing as expected. This is where the performance engineering business gets importance over all the activities. If I ask you, is this the stage to give importance to performance consideration? The answer is definitely NO. I know you are saying that the performance should be considered from the very first day. If this is known, then why so many application end up in the above situation? Why do we raise our heads for performance at the end of everything? Let us discuss this problem and try to find an easy solution to it.

The question is – ‘Where did it go wrong?’ The answer can be at the very first stage i.e. requirement analysis or it can be almost the last stage of unit testing, or anything between these two stages. Performance is that requirement which exists since the beginning of the project, and which never gets tracked thoroughly and implemented completely. This is the cause of failure for many applications during performance testing cycle or in production due to bad performance. During application development cycles, the focus is clearly on functional requirement fulfillment rather than non-functional requirements such as performance. Throughout the development cycle, people focus on how to solve the problem; easily, with something basic, that can be implemented quickly without diverting focus of application developers from the core of the application. Below are the top 10 points, if considered in through lifecycle stages, will make you sail smoothly without any turbulence of last minute performance issues. There are n-number of things one would need to consider in an application. But out of those, here are the fundamental ones with which you can address performance problems of almost 80% of the projects.

Performance engineering is a continuous process during application development. Each lifecycle stage requires a couple of things to be implemented rigorously. Let us take each stage and see what is applicable there.  If your development model is water fall model, then these stages may be visible clearly, if it is agile methodology applied to small modules, then these stages may not be visible clearly. Still these 10 points will have to be considered to address performance concern.

Requirement Analysis:

1.       Validate Non Functional Requirements (NFRs): Collecting non functional requirement is a simple activity during requirement analysis phase but there is another counter part of it. It is validating these requirements. Checking if these requirements are feasible. If we do not validate feasibility, then we might commit something that is not technically possible under a given situation. Example would be a data intensive web application expecting 1 second page response time on websphere. You may want to consider the following things -

• Industry or previous experiences with websphere for similar applications
• Amount of data being processed to respond
• Impact of all components involved between request and response

If there is no such data available then go for a small proof of concept, but do not accept the requirement without analysis.

Architecture and Technology

2.       Architecture and Technology that suites NFRs

In the requirement stage, you have validated and finalized requirements. When you define architecture and choose the technology, these NFRs will play an important role.

• Number of layers, how the components are grouped and deployed, which logic resides where, etc. considerations do impact the processing time.
• If your application requires high performance you may choose to reduce xml processing as well as avoid using web services. Similarly technology should be selected according to performance requirement.

3.       Seamlessly Integrating Technologies

Mostly, technologies from same vendor integrate seamlessly. Hence, while selecting technology, select from same vendor. There is a risk of having dependency on a single vendor, but judicious selection can avoid it.

4.       Remote or Local

Remote access technology requires conversion of data in a form that can be transported over network. When it reaches destination, sometimes it needs to be converted back to it’s original form. This conversion is definitely time consuming. When you decide whether to go for a remote call, just check if you really want to distribute the components? If possible avoid it and improve performance. E.g. you think that in future you might have to expose your application services to world, hence you expose all the services as web services . This means your own application UI will also require it to be accessed as a web service. Instead of this, just exposing the required services as web service interface to external world would improve performance of your own local UI.

Design

5.       Reduce Network Traffic

How many calls you make to the database to process a certain request, determines the network traffic you create between the application server and the database server. A similar case is – jsp making number of calls to the middle tier java components to fetch data. In both the scenarios, more number of round trips, reduce performance considerably. Design in such a way that there are lesser number of network trips. Usage of façade pattern in services offers coarse grain interfaces to callers, who can get more in a single call.

6.       Let Minimum Data to Flow Across

More data means, more load on network, more memory requirements, more processing and finally more time. Apply simple rule, reduce data at the first stage itself, and transport only required data over network. This has been a major design problem in many applications. It increases load on all the resources.

7.       Performing Logics

During design phase, you may have to define pseudo code for some functional requirement. If you ask ten different people to come up with it, I am sure you will get more than 70% people having different logic. If you analyze those from performance point of view, you can clearly distinguish few of them. Whenever you are finalizing design for some complex or data intensive logic, check if the design is better in terms of memory and performance both.  See if the loops are running optimum number of time and you are not creating big memory footprint while executing them.

Code

8.       Use Correct Technology Elements

Languages have all kind of elements or APIs. Each of them has some specific use. Some of the data APIs support additional functionality but with a performance burden . When you write code, also take care of these aspects. E.g. in Java, you have collection framework. Most of the collection objects require initial size definition for better performance. Also, collections like vector provide synchronized operations which slow down additions and removal of objects to it. Hence you need to choose the technology APIs correctly after looking at your requirements.

9.       More Memory Less Performance

Technologies like Java support garbage collection to free up un-used memory, while in case of C++ you need to manage it on your own. As memory goes on reducing the performance degrades. Even though Java supports garbage collection, heavy load on garbage collection reduces speed. Also memory leaks do not allow garbage collection. Hence when you use memory use it judiciously and try to free it up when done, instead of waiting for automated clean up. If not for all, at least apply this to heavy variables/objects.

Test

10.   Early tests to catch bottlenecks

The rule is to catch problems early to fix at a lesser cost. You may have tried to follow all of the above points, yet there will always be something that can hamper your application performance. Unit testing is the first stage where you test your application, try to focus on performance in this cycle of testing to catch problems early. Frameworks like JUnit have started supporting performance testing also. Correcting problems at a later stage involves huge cost. Hence use early opportunities to detect problems.

Summary:

Performance is an inherent requirement for all applications, but most of the times it is addressed in a reactive mode, when the actual problem is reported. Fixing this problem at a later stages involve huge cost. By simply following the above simple guidelines will help the application developers to reduce the last stage problems considerably and take you through the performance testing cycle smoothly. 

More Related Posts in Featured, Tech Notes