I have done some searches on this topic, and it seems that almost everyone recommend to use a copy of PROD environment to do such tests
For example this answer on SQA: click and also I've reviewed Microsoft's Performance Testing Guidance for Web Applications and some other resources.

and I actually know that testing on scaled down enviroment has a little value.

But in our case this is not an option- our Boss roundly said that we can't afford for a copy of PROD, and we must use much smaller testing environments to do performance tests.

I am looking for an information how to plan and organize such test in a sensible way ? What kind of tests we need to implement ? What data/metric we should collect ? What kind of problems can be/ or cannot be catch by this "reduced" test ?

Our PROD environment consists of 6 application servers, 2 database servers and a few auxiliary servers, the whole system supports about 200-400 simultanous users (on average).
Test environments are much smaller.

  • Why do you (or your boss) think that performance measured in environment significantly different from PROD would be any relevant to results in PROD? IOW: Please try how pretty would be bride in a white dress, and use this blue dress for that. Commented Jun 7, 2016 at 20:59

2 Answers 2


It is obvious that you won't be able to produce high loads on a scaled down environment, however there are few things you still can check:

  1. Memory leaks. If your application has unclosed streams, unflushed data, memory is allocated but don't freed up, etc. it may run out of memory and it is much easier to detect the trend on a smaller system.
  2. Bad code. You should still be able to run your application under a Profiling Tool telemetry so you could detect the most memory/cpu hungry code bits.
  3. Underlying software configuration issues. You can quite easily test whether i.e. application server and database server are well-configured, as i.e. if application server requests 100 connections and database accepts only 50 the remaining 50 will wait in queue resulting in worse performance while system is idle.

See Performance Testing in a Scaled Down Environment. Part Two: 5 Things You Can Test article for few more suggestions on what you can do, however the best option will be to consider testing on PROD in "dead" time like weekends or nights, if your application assumes such "dead" times.


The sorts of problems you're looking for in a performance test have to do with load, locks, bandwidth usage, response time, and so on. And they don't scale in either direction.

You will find performance problems in the smaller environment that the larger one would never experience, and you'll hit problems in the large environment that the smaller one couldn't find. So you'll end up fixing problems that don't matter, and not finding the ones that do.

I realize this isn't answering the question, but there isn't a good answer to the question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.