Where are your bottlenecks most likely to occur? If you are developing an ASP.NET application on SQL Server, the first set of bottlenecks usually occur in the SQL layer, followed by the mid-tier ASP.NET code. The problem almost never lies in the static content that the web server serves up.
In fact IIS is extremely efficient at serving up static content. At the same time, requesting static content is very taxing on the load agent. Typically we see load agents running out of CPU first, and the short, fast request/responses for static content end up chewing up most of the CPU. If you think about it, this makes sense. 10 requests for small gifs, each with a response time of 5 ms will use more CPU time on the load agent than a single request for a larger aspx page that returns in 500 ms. So unfortunately an agent can spend more resources making requests for static content than for the dynamic content where the problems lie.
If your goal is to find bottlenecks in the mid-tier or data tier, I recommend either setting Percentage of New Users to 0 — this will cause the user’s cache to fill up, causing the load test engine to request less static content, or better set Parse Dependent Requests to false in your web tests. I really wish we had a setting on the web test node to control the latter, but that will have to wait until next release. Note that when you do this, your pages will look strange in the browser preview in playback because the engine will not request the gifs and css files on the page.
We recently had a dogfooder who was seeing CPU spikes on his load agents. When I had him turn off parse dependent requests, he saw the smooth CPU line he was looking for on the load agent. Part of the problem was that he didn’t ramp vUsers on properly, causing a periodic burst in CPU. But the other part was that the static content was making the agent work much harder.