Home/ Questions/Q 610457
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T17:40:39+00:00

I’m very new to performance engineering, so I have a very basic question. I’m

  • 0

I’m very new to performance engineering, so I have a very basic question.

I’m working in a client-server system that uses SQL server backend. The application is a huge tax-related application that requires testing performance at peak load. Meaning that there should be like 10 million tax returns in the system when we run scenarios related to creating tax returns and submitting them. Then there will also be proportional number of users that need to be created.

Now I’m hearing in meetings that we need to create 10 million records to test performance and run scenarios with 5000 users and I just don’t think it is feasible.

When one talks about creating a smaller dataset and extrapolating the performance planning, a very common answer I hear is that we need to 10 million records because we cannot tell from a smaller data set how the database or network will behave.

So how does one plan capacity and test performance on large enterprise application without creating peak level of data or running peak number of scenarios?

Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Now I’m hearing in meetings that we need to create 10 million records to test performance and run scenarios with 5000 users and I just don’t think it is feasible.

    Why do you think so?

    Of course you can (and should) test with limited amounts of data, but you also really, really need to test with a realistic load, which means testing with the amount (and type) of data that you will use in production.

    This is just a special case of a general rule: For system or integration testing, you need to test in a scenario that is as close as possible to production; ideally you just copy/clone a live production system, data, config and all and use that for testing. That is actually what we do (if we technically can and the client agrees). We just run a few SQL scripts to randomize personal data in the test data set, so prevent privacy concerns.

    There are always issues that crop up because production data is somehow different from what you tested on, and this is the only way to prevent (or at least limit) these problems.

    I’ve planned and implemented reporting and imports, and they invariably break or misbehave the first time they’re exposed to real data, because there are always special cases or scaling problems you didn’t expect. You want that breakage to happen during development, not in production :-).

    In short:

    Bite the bullet, and (after having done all the tests with “toy data”), get a realistic dataset to test on. If you don’t have the hardware to handle that, then you don’t have the right hardware for your tests :-).

    • 0