The iteration model describes at a technical level how the test object will be loaded and how the performance will be measured. A load model describes the required loading. In practice, that should be achieved through a spread of users who will gradually generate the desired level of traffic. For if all the users were to start at precisely the same moment, their actions would run concurrently over a long period. If, for example, a file is downloaded, all the simulated users will do it at about the same moment. This usually isn't realistic users' behavior. An iteration model describes the (technical) way in which the loading is spread out, so that a dynamic mix of actions can be achieved quickly, which can then be maintained for a certain length of time. An iteration model is dependent on the performance test tool, since it describes how various tool scripts and users operate in relation to each other.
Number of transactions per hour:
For the generation of this load, the final number of users simulated and both the number and frequency of transactions per hour need to be matched to the stated requirements. This also requires a realistic estimate of the likelihood of situations in production. For instance, it's extremely unlikely that the users of a back office application will all log in at the exact same time. It is, however, very likely that an email from an online store or ticket sales promotion will result in large numbers of users connecting at basically the same time.
The combination of load and iteration model provides the end-user load scenario that performance testing will aim for. The back office application can still be tested for 1000 simultaneous logins but that will be a separate Load and Iteration Model for that specific stress test scenario.