Using load testing tools

Load testing tools help you determine how your model will perform once deployed.

Before using the load testing tools:

  • Understand what is being tested.
  • Isolate your test cases so that you know what the impact means (local vs. remote LAN testing, testing with and without clustering, with and without web fronting, and so on).
  • Understand that as models change, so must any scripts that you use to perform testing and replay test scenarios.
  • If they are more global than the current model group, then define them at the lowest point in the model group tree that is an ancestor of a model where you wish to use the property.

The rule firing trace has three columns:

  • A sequence number, useful for communicating with others about rule issues. It's easy to tell someone, "See line 35, where it says Xxx?"
  • Elapsed time. This logs how long it took from the time the log entry was made until the start of rule firing.
  • The body of the trace log. This displays the aspects of the rule firing, such as a condition being evaluated, an assignment occurring, the start of a rule or the conclusion of a rule, and so on. The log also displays the following aspects:
    • The number of milliseconds needed to fire a rule after each rule firing entry.
    • The total number of milliseconds needed to run the model is logged at the end of the rule firing trace.
    • The messages written for constraints as part of rule and constraint evaluation.
    • The number of milliseconds needed to apply a constraint, after applying each constraint

The property pool trace also presents three columns:

  • Name is the full path name to the item and the property on that item.
  • Type is the property type for the named property, such as Numeric, List, or String.
  • Value is the value of the property after the rule has fired.

The following illustration shows a section of a sample property pool trace:

Use this log "single user" to get a feel for how extensive the rules are per click. Check how long is it taking to fire the rules. If the answer is more than 100-200ms you may have scalability problems. If you do, use the trace log to figure out if any particular rules are performing badly.