One of the most difficult things to deal with when performance testing is security. It is designed to stop the very things we need to do to generate server load. Basic security protects a system from robot attacks, multiple logins, invalid permissions, and more. Many of the techniques used in performance testing are similar to attacks that attempt to compromise a system.

How do you deal with security then? I usually ask that it be turned off on the systems I am going to test. A lot of time and effort can be wasted trying to make an application play by the rules. For example, if a system allows only one login at a time and you need to simulate 1000 clients, you will need to have 1000 users defined. Worse, you will need to manage the use of all those logins across the machines being used to run the performance test. It becomes a data management nightmare and can cause endless frustration.

Some security rules only allow one instance of an application to connect to the server from an IP address. This makes it impossible to use a tool that spawns multiple threads or processes to simulate multiple clients.Now it might be impossible to turn security off or there may be rules against it. If that is the case then there are not a lot of options. But if it is at all possible, I suggest that you have security turned off while doing performance tests and avoid all of these problems entirely.