The goal of long run testing is to be able to find and narrow down the source of software failures that are provoked by long running of the software. These tests are ideal for stimulating and finding memory leaks within your code or possibly frameworks you rely on.
Remember! Your software can only be as good as the third party software you utilize, so it is always good to start at a high level when performance testing.
In addition to capturing software metrics, it should also be noted that it is critical to capture the metrics and trends of the system the software is installed on. Understanding the impact the software has on the base system can lead to better longevity performance. I recommend using built in tools or simple scripts for monitoring the following base metrics (add more detailed metrics depending on your software):
Reviewing the results from our long run scripts has potential to show increasing memory usage without deallocation. The next steps is to narrow down where the memory is leaking from. Is it our code? IBM code? etc. To help in ruling out our code in being the culprit it is ideal to use a third party profiler. The following is a list of different profilers recommended: Yourkit – this is good for java profiling. JConsole – a free java monitoring application provided by Sun. Also does historical collection! Valgrind – useful for C and C++ profiling. Valgrind is free under the GNU General Public License, version 2.
Depending on the type of defect that was discovered during long run, different approaches can be taken. As we discover new problems through our testing I’ve attempted to document the resolutions here.
If the results of diagnosing the memory leak through Yourkit has pointed towards our agent being the problem, it is then up to our developers to find the buggy code and resolve the issue. Keep in mind this means that the Yourkit results shows leaks for the kp8/kp9 dataprovider (PeopleSoft) or the kubsieb/kubfilesys (Siebel). These are the portions of the agent we are responsible for.
If the results show leaks for any other portion of the agent, it is then on us to confirm its not our agent provoking the leaks, then send the details to the agent factory team to fix. However, if the results of Yourkit are negative we can then infer that the problem relies in the JVM. Usually this can be resolved by us using a newer version of the supplied IBM java. Make sure to do your research! Look through IBM technotes or APARs for known defects with the JVM.