Getting Reliable Results

APE's test results can be affected by other application and network events. The following list will help you achieve the most reliable test results.

• Do not run any other applications on the machines that APE is using for its tests. Other applications can randomly consume memory and CPU cycles, making it hard to achieve consistent results with APE.
  
  
• For the fastest possible performance results, use a private network between all APE machines, or at least try to run APE tests at times when network traffic is minimized. On the other hand, running your APE test during typical network traffic conditions may present a more realistic test scenario.
  
  
• Run multiple tests, discarding the results of the first run that often has unique setup costs. Long tests (using hundreds or thousands of calls) will produce more accurate average numbers.
  
  
• Test performance can vary at different times of the day or with different hardware configurations. To guarantee that tests are repeated accurately, you can use named profiles to save and recall test settings. If further control is needed, custom test scripts can be easily written in VB (or a VBA application like Microsoft Excel) to control the tests through APE's COM programming model.
  
  
• APE's performance tests can be customized to match very specific application scenarios by modifying the APE source code, recompiling the changed components, and redeploying and reregistering the modified components to the appropriate machines. The two components that emulate business object behavior and will likely be the most interesting to customize are AeServic and AeMtsSvc.

  Note   The Visual Basic source code and project files for all of APE's components are located in ..\Program Files\Microsoft Visual Studio\Common\Tools\Ape\Source.

• After running a test, you can verify the successful completion of write queries and MTS transactions by looking for changing values in the ACCOUNT table of the APETEST database. Each Simple Write query adds one dollar to an account selected randomly from a range of one through 1000. Each Simple Transaction query moves one dollar between two accounts selected randomly from a range of one through 1000.

For More Information   For more information on monitoring MTS transactions, see Monitoring MTS Transactions.

• If your client configuration does not send or return data, all the client is doing is submitting the call. As your test is running, the client's Calls Returned count merely represents how many calls were accepted. If your test is also using queuing, the Calls Returned count will quickly reach the designated test amount — even though the queue may still be handling various CPU or database tasks. This is expected behavior. To actively involve the client in a relationship with the queuing activity, you must configure the test run to Return Data to Client (on the Return Data tab of the Client Options dialog box).