and our client need we to simulate 50 person to work at the same time on the website, and the response time should be within 5 seconds. But our concern is that if we test at their website, we can not control the network speed, hardware and so on. As that might effect our test result. and another thing is there are some antiforgerytoken in our website, the performance test tool can not simulate this mechanism, after we record the request, and system send it again, it will fail, since the token is invalidated. and I want to know how do you perform this performance test usually ? any suggestions ? Thanks in advance !
When running load tests, it is really best to emulate your environment as best as possible. If the resources of the test system are different than the production system, you are bound to get different results.
Still, you can run tests with given hardware and report on the numbers you get. For instance, you can know how much bandwidth your system needs regardless of how much the production system has available because that can be measured.
But if you want to measure against what the client will see, you have to do it with the same environment.
My usual approach is phased.
First, test in the development environment using a simple tool like WCAT. It won't run JavaScript or do postbacks, but it will stress simultaneous requests and threads, which are often major performance bottlenecks.
Once that's working as desired, then move up to Visual Studio Team Test, which supports more complex scenarios. Start in the lab, and then move to a beta / pre-production environment. I also like to use server-side performance counters and monitoring, in addition to or sometimes instead of client-side measurement.
For the anti-forgery logic, for load testing purposes only you might build a version of the system that doesn't have that check.
Next, test with real users in a beta environment. The details depend on the project. If I can't get real users, I've also created setups with tens of PCs running test scripts with real browsers. There are some good third-party tools that can help here, too, such as Load Runner (expensive, though).
Finally, continue to monitor and test once the software goes into production. It's not uncommon for software that works great in beta to fall apart in production due to some unforeseen difference or inconsistency (IIS config, for example).