Common troubleshooting steps
WebSphere Commerce applications can be complex and as such troubleshooting performance problems can be one of the most important and complex tasks in the your site development cycle.
Here we discuss a general strategy for troubleshooting performance problems:
- Set up the test environment.
This includes your WebSphere Commerce site as well as any test tools required.
- Warm up your site and back up your site before test execution.
Before starting your test run a test to warm up your test environment. Warming up refers to running a very small load on your site for long enough so that various caches can be populated and the database can build an access plan.
IBM recommends that you take a backup of your database after this warm-up so that you have a clean restart point should you need to rerun the test case later on.
After you take the backup and restart the WebSphere Commerce application you will need to rerun through your scenario at least once before executing your test case so that Dynamic Cache can be populated.
- Narrow down the part of your scenario causing the performance concern.
This is to isolate the problem so that you can focus on it without being distracted by any other interaction. Once you have narrowed down the interaction or the set of interactions that may be causing the performance concern, this would also make it easy for your to reproduce the problem quickly.
- High error rate.
All functional defects (which can be reproduced always even by a single user, for example, without load on site) should be resolved prior to starting performance testing since finding functional defects by doing performance testing is very expensive due to time and resource required for performance testing. However, it is possible that some functional defects were not caught prior to running a performance test and thus generate errors.
If, however, the errors are caused due to concurrent users accessing the site, then it is possible that code-related or database-related deadlocks may be causing the problems. In such a case more detailed tracing may be required to isolate the problem. It is also possible that such problems may be caused due to system configuration such that it is not able handle high workload causing overflows or time outs.
In remaining part of this chapter we explore strategies for addressing memory, throughput, and response time concerns in greater detail.
