NBomber "Pacing" (Hitting an Exact Transactions per Hour)

[CMorrisonJHA]

[ 1/22/206: I am refactoring this discussion post to a more definitive answer instead of a question. At least an answer that's working for me.]

Goal: I want to mirror a Production load exactly (and do this by reading numbers from a Production monitoring tool such as AppDynamics.). I want to be able to plug in throughput targets and then hit those goals exactly in the load test.

JMeter has this feature, implemented by means of "timers." Like "Constant throughput timer":

LoadRunner has this feature implemented by means of setting users to a fixed (or random) iteration rate.

Visual Studio has this feature, implemented by means of its "Test Mix Model" and the "Test Mix Based on User Pace."

The goal of this feature is to guarantee hitting a particular number of transactions per hour.

Often, an organization will have a Production monitoring tool such as Adobe Analytics (formerly Omniture), or they can get peak hour transaction data from a database. With the above type of "pacing" feature, we can program the Production load right into the load test before we even run the test.

I am including a screenshot from Visual Studio of it's "Test Mix Based on User Pace", although . I think the above description about a "fixed interval between the beginnings of each iteration" is the clearest description. That is how LoadRunner does it. I think that Visual Studio does the same thing, but it just calculates the Task.Delay() for you. You put in the number of iterations per hour you want 1 user to do for that "step." Then, we can increase the number of users or threads, but the "mix" of requests remains at the same ratio (as you ramp up the test.)

The benefit of this feature is that you can look like a genius when doing Production testing: you can hit the Production peak hour exactly and not exceed it. (Exceeding the peak hour always causes a bunch of people to say that "you did not find a load bug," because "you hit the system too hard." )

With the correct pacing time you mirror the Production peak load exactly. Then, if the system falls over, the bug is in the application under test and not in the load test.

1/22/2026: In the next comment below I will post an example to achieve this goal.

Appendix: Further Notes on this Feature

See also:

• https://community.opentext.com/devops-cloud/ppe/f/discussions/99379/how-to-calculate-pacing-time-in-load-runner
• Note that the name of the LoadRunner setting is deceiving. The name says "an interval between iterations."
• But if you look at the tool tip of VUGen, the tooltip says "You specify the time between iteration—either a fixed number of seconds or a range of seconds from the beginning of the previous iteration. Each scheduled iteration will only begin when the previous iteration is complete." See: "https://venkatmatta.com/2016/03/23/vugen-runtime-settings/
• https://performancetestingcentre.blogspot.com/2013/08/what-is-pacing-time-and-why-to-use.html
• If you are into math, this is an explanation via "Little's Law:" https://theperformanceengineer.com/2013/09/11/loadrunner-how-to-calculate-transaction-per-second-tps/
• Also a good explanation: http://loadrunnertips.com/VuGen/vugen_pacing_interations.html : "In this option an interval is set and this interval starts when the vuser starts the iteration. If the vuser iterates within the specified interval then the it waits for the remaining time until the interval is over. For instance, if the interval is set to 60 sec and the vuser iterates in 40 sec then the remaining time becomes the pacing i.e. the vuser has to wait for 20 sec before starting the next iteration. If the Vuser surpasses the specified interval, let us say it takes 65 sec then it proceeds to next iteration without waiting. In such a case the log displays a message that says “Iteration pacing cannot be reached (pace time = 60.00, actual time = 65.00).”
• https://www.perfmatrix.com/loadrunner-runtime-settings-pacing/

The way pacing essentially works is that it marks the start time of each request (or "step," or group of requests.) It is setting a fixed interval between the beginnings of each iteration.
Beginnings is the key idea. The "calculated pacing" feature in the above tools is not affected by abnormally long response times. For the most part, it's OK if the requests are abnormally slow, because the idea here is not a fixed pacing AFTER a request ends, the pacing is measured from when the request begins. The next request will start at the same fixed pacing interval regardless of how long the request took. E.g.: Task.Delay((fixedPacingInterval- elapsedMs));

This procedure allows us to hit the exact number of the requests or transactions per hour as seen in the Production monitoring tool (the Production peak hour.) It allows us to do that without a lot of experimental load testing.

[CMorrisonJHA]

Here is the approach I am using

1. Go to your Production Application Performance Monitoring tool (APM), such as Application Dynamics. Gather the requests per hour for a peak hour .
   Our goal is to mirror these in the NBomber load test.

2. I Used Excel to do some calculations. (Note 1/22/26: This Excel table needs updating/elaboration in this discussion. The point is that some pre-work is done in Excel to get an idea of your pacing.) E.g.:

<style> </style>

Request	Iterations / User / Hour	% of Total	Pacing Time (Delay before next iteration) (millseconds)
GetCustomer	690	28%	5217
Update Risk	690	28%	5217
Update Customer	690	28%	5217
Get Accounts	211	8%	17062
Add Account	201	8%	17910
Update Account	9	0%	400000
Add Customer	3	0%	1200000
Target Total Iterations/hour for the target Workload	2494	100%

3. Use NBomber's "Run Multiple Scenarios In Parallel" Dynamic Workload to create different load tests.

• These are equivalent to "scripts" in LoadRunner or JMeter. They are "flows" of requests, but we will run each one as a separate load test with a different number of users assigned to it.
• Use a Dictionary to Assign Users (Threads): split a total number of users amount the different load scenarios.

Listing 01: A Main Test Class to Launch Multiple Scenarios in Parallel

 [TestClass]
 public class CapacityTestWithInitialAndMaxUsers
 {
     private readonly TimescaleDbSink _timescaleDbSink = new();

     [TestMethod]
     public void LT_MobileHiVolume_Capacity()
     {
         int initialUsers = 40;
         int maxUsers = 100; // Change this for capacity tests. The dictionary keeps ratios of users assigned to the load tests the same.
         int durationInMinutes = 1;

         var ratios = new Dictionary<string, double>
         {
             { "Enrollment", 0.43 },       // 43%
             { "Approval", 0.09 },         // 9%
             { "DepositCheck", 0.42 },     // 42%
             { "ViewDepositHistory", 0.15 } // 15%
         };

         // Distribute users for both initial and max
         var initialUserDistribution = DistributeUsers(initialUsers, ratios);
         var maxUserDistribution = DistributeUsers(maxUsers, ratios);

         int enrollmentInitCopies = initialUserDistribution["Enrollment"];
         int approvalInitCopies = initialUserDistribution["Approval"];
         int depositInitCopies = initialUserDistribution["DepositCheck"];
         int viewInitCopies = initialUserDistribution["ViewDepositHistory"];

         // Use whichever distribution you need for your scenarios
         int enrollmentMaxCopies = maxUserDistribution["Enrollment"];
         int approvalMaxCopies = maxUserDistribution["Approval"];
         int depositMaxCopies = maxUserDistribution["DepositCheck"];
         int viewMaxCopies = maxUserDistribution["ViewDepositHistory"];

         var enrollmentScenario = EnrollmentScenario.Create(enrollmentInitCopies, enrollmentMaxCopies, targetIterationsPerHour:135, durationInMinutes);
         var approvalScenario = ApprovalScenario.Create(approvalInitCopies, approvalMaxCopies, targetIterationsPerHour:30, durationInMinutes);
         var depositCheckScenario = DepositCheckScenario.Create(depositInitCopies,depositMaxCopies, targetIterationsPerHour: 135, durationInMinutes);
         var viewDepositHistoryScenario = ViewDepositHistoryScenario.Create(viewInitCopies, viewMaxCopies, targetIterationsPerHour: 15, durationInMinutes);

         NBomberRunner
             .RegisterScenarios(enrollmentScenario, approvalScenario, viewDepositHistoryScenario,)
             .LoadInfraConfig("infra-config.json")
             .WithReportingSinks(_timescaleDbSink)
             .WithTestName("MobileHiVolume")
             .Run();
     }

    // Helper method to distribute the threads among various load tests.
     private static Dictionary<string, int> DistributeUsers(int totalUsers, Dictionary<string, double> ratios)
     {
         return ratios.ToDictionary(
             kvp => kvp.Key,
             kvp => (int)(totalUsers * kvp.Value)
         );
     }
 }

Notice in the above that I am taking the number I got from Application Dynamics, the target transactions per hour, and passing it to a method which creates each load test for me. This main class, just registers the scenarios.
To set up the load test see the listings in this other NBomber discussion.

[CMorrisonJHA]

1/22/2026. This is working well for me.