LoadRunner Runtime Settings: A Practical Guide to Realistic Workload Modeling

When running training sessions or mentoring engineers, one question comes up repeatedly: “What runtime settings should we use?” As if there exists a universal configuration that works for every performance test. There isn’t. Runtime settings must always align with the objective of the test. However, in practice, there is a core set of principles that apply to most real-world scenarios. Understanding these is far more valuable than memorizing settings.

For scripts that support multiple actions, the most effective approach is to model business processes explicitly. Create a separate action for each business transaction and assign percentage weightings to reflect real production usage. This provides a simple and scalable workload model. Complex constructs such as sequential execution or action blocks are rarely required. One exception is when fractional execution is needed, for example 0.1 percent. Since LoadRunner supports only integer percentages, this can be approximated using nested blocks. In most performance tests, scripts are executed based on duration, not iteration count. Iteration-based execution is typically limited to debugging in VuGen.

Pacing is often misunderstood and misused. The option “as soon as previous iteration ends” is useful for debugging or data validation but should not be used for load testing. Fixed pacing can lead to synchronized user behavior where multiple users hit the system at the same time, creating artificial spikes and unrealistic load patterns. A better strategy is to use random pacing intervals while ensuring that the average iteration time aligns with the target throughput. The lower bound of pacing must not exceed the maximum execution time of the business process, otherwise the system will generate fewer transactions than intended.

Logging introduces overhead and should be used carefully. During debugging, full logging is appropriate. During load execution, logging should be minimized. A balanced approach is to enable extended logging but configure it to log only when errors occur. This provides visibility without impacting performance.

Think time simulates real user behavior and must not be ignored. A good practice is to use randomized think time, typically 50 to 150 percent of recorded values. Think time should only be ignored during debugging or data setup. Removing think time during load testing results in unrealistic, bursty traffic that does not reflect actual user behavior.

Additional attributes are often overlooked but highly useful. They allow runtime parameterization without modifying the script. For example, defining a parameter such as ServerName allows you to switch environments directly from the Controller. This simplifies testing across multiple environments.

Several miscellaneous settings are important. Continue on error should be used only if the script includes explicit error-handling logic. Failing open transactions on error should always be enabled to ensure accurate reporting. Generating snapshots on error is useful for debugging and failure analysis. Running virtual users as threads is generally preferred because it reduces memory consumption. Running as a process should only be used when required, such as when dealing with non-thread-safe code. Automatic transaction creation options should be avoided. Transactions should be explicitly defined using lr_start_transaction to maintain control and clarity.

Network speed simulation should be used intentionally. In most scenarios, virtual users should use maximum bandwidth. If bandwidth constraints need to be tested, such as for mobile users, this should be done in a separate scenario. Mixing different bandwidth profiles in a single test can distort results.

Browser emulation is often misunderstood. The User-Agent setting only changes the HTTP header sent to the server. It matters only if the application serves different content based on browser type. Otherwise, it has no impact on performance behavior.

Proxy configuration should reflect the actual production architecture. If users do not go through a proxy in production, it should not be included in the test. Proxies can introduce additional latency, create misleading errors, and interfere with load balancing behavior. They should only be included if they are explicitly part of the system under test.

Download filters help control external dependencies. A common use case is blocking third-party analytics or tracking domains. A better approach is to explicitly allow only required domains rather than selectively blocking some. This reduces the risk of missing hidden dependencies.

Content checks are one of the most underutilized features. Without validation, failed responses may still be counted as successful. Content checks ensure that responses are not only fast but also correct. This makes test results meaningful and reliable.

Runtime settings are not just configuration parameters. They define the behavioral model of your load test. If configured incorrectly, throughput will be inaccurate, concurrency will be unrealistic, and bottlenecks will be misidentified.

Performance testing is not about executing scripts. It is about accurately simulating user behavior at scale. Runtime settings are where system behavior, user interaction patterns, and workload distribution come together. Getting them right ensures that your test reflects production reality. Getting them wrong makes even a perfectly scripted test meaningless.