I've run into this kind of stuff, too, and I think there are a few more
points that might be useful to make here:

1) requests/second is interesting but not overly so - *throughput* is
actually a more interesting measure.  You can swamp any web server near to
death with concurrent requests and while it stays alive, it may be serving
300, 400, even 500 requests/second but if that comes at the expense of having
your per-page response time going to 10 or 12 seconds it's not good.  Also,
with a flood of concurrent connections, you may keep the asp work queue full
at all times, achieving a flat request/sec stat, but that doesn't mean it's
performing well.  In other words, you can jam a lot of people into a doorway,
but there are consequences.

Look at time to first byte, time to last byte and average times, not just
requests/sec.

2) With the 50 concurrent requests, you see a lot of spiking because your
service can handle that level of concurrent requests reasonably well; the
troughs are due to the testing engine turn-around time.  When you have a
testing engine - like ACT or WAST - they're going to fire off a bunch of
concurrent requests, wait for the responses, collect some statistics, turn
around and do it again.  If the number of concurrent requests is well in
range of your server capacity, all the responses will be in more or less
constant time, so all 50 start at the same time, stop at the same time, and
get reissued at roughly the same time.  So they're all moving in relatively
lockstep.  That's why it's hard to get a true emulation of real-world use.

3) I haven't used ACT, but I've used WAST a lot.  It's a great tool, but a
couple of observations:
a) use more threads and less sockets.  For some reason, the driver overhead
is a lot more with more sockets.  When you use a lot of sockets and fewer
threads, that really exacerbates the spiking you were seeing.

b) Wherever possible, split up your test runs across multiple physical
machines.  There are very concrete limits to how well WAST can drive a high
flow of traffic.  If you really want to stress test a lot of concurrent
connections, having one box with high thread/socket settings, you'll quickly
run into granularity effects in how fast WAST can turn around that number of
requests - a lot of driver overhead will creep into your stats and coarsen
your results.  Running the same WAST script from 5 client boxes with 10
concurrent connections each will work a lot better than running it on one
with 50.

Thanks
-Mark