I am more than a little skeptical about standard web stress tools working correctly with VWG, given that this a 100% ajax application.
Most stress test tools use URL Get/post requests to simulate user traffic. That is not going to work with VWG - you actually need to have something interact with the surface of the application to trigger a realistic response. Remember, the main URL never changes with VWG.
I should mention, however, that I did not try to use the latest generation of stress tools (such as those that Daniel recommended), and these tools may do a great job of testing AJAX calls.
In our case, we used a more brute force approach: We created a 'stress test mode' in the application that basically invokes every node in the main tree using a timer, and then logs the results to a file. We then solicted a large group of users to create 10 IE browser windows each, logon as a different user in each window, and start the stress test mode. We comfortably hit 85 concurrent users on a single box with about 2-5 seconds response time when changing screens (selecting a new node in the tree).
There may be more sophisticated techniques, but the way did it simulated an actual user experience of accessing evey node in the application tree. We then reviewed the logs to see how the performance was impacted.
On the subject of deployment, we did some experimenting with application pools. As you know, IIS uses application pools to actually run the web processes. VWG 6.3.xx does not support web gardens (which is a application pool configured to have multiple processers). Since you must have a single processor pool, we created multiple virtual directories on the web server, each of which points to their own application pool (e.g, Site1uses Pool1, Site2 uses Pool2). This effectively spreads the load across the machine in much the same way as a web garden. When our users access the application, they come into a simple html page which redirects then randomly to site 1,2, or 3. You could create any number of virtual web sites using this technique... we stopped at 3 sites.
We do have to recycle IIS overnight. I am not sure if our application is slowly eating memory, or if the problem is in VWG. I have a suspicion that VWG is not releasing the default main form even if the session is closed. In my testing, I cannot get the Main form destructor to ever fire. That tells me that something is holding onto it... maybe someone else has some insight into that issue.
Hope our experiences are helpful.
Mitch Stephens