During my career as a performance engineer, I worked in several performance testing exercises.  You can imagine that I experienced all kinds of challenges regarding estimation and simulation of realistic load patterns. There are some pitfalls which you should avoid.

Initially, you have to clarify whether you’re going to test a brand new system or if it’s already in production. The correct pattern for the latter can easily be derived, but the former is, of course, more challenging.

A brand new application

Let’s assume you are going to prepare a workload for a new business application. You have no reference system or production environment where real users are doing day-to-day activities. All that your customer told you is how many users are going to use this business application in the future. How many concurrent users will you simulate?

I use little’s law in such cases because this allows you a realistic calculation.

Little’s law: Latency = Load / Throughput

Throughput: Expected number of business transactions per interval

Latency and Throughput are often part of non-functional requirements.Let’s calculate the load or concurrent user for this example:

Number of users: 1000 user will work with the new application
Latency: 30 seconds for a typical business transaction
Throughput: 600 transactions per hour
Load: 30 * (3600/600) = 180 concurrent user

Given the sample above you can schedule a performance test with 180 concurrent users. There is absolutely no need to run a test with 1000 concurrent user because those will most likely never use this application at the same time.