1

I'm using WCAT to load test my app, and I want to see the traffic in fiddler.

When I run the WCAT script, it runs OK,but I don't see any of the traffic in fiddler... Do I need to configure fiddler to proxy WCAT traffic?

The web app I am testing is on my local machine, but I'm not addressing it with "localhost", I'm using the name of my machine in my settings config. I don't have any filters set up in fiddler either.

EDIT:

Here's my transaction I'm testing with (the ipv4.fiddler is a recent addition as per a suggestion below):

transaction
{
    id = "add a new user";
    weight = 1;

    request
    {
            verb = POST;
            postdata = "Name=Bob+Smith&Gender=M&DateOfBirth=01%2F01%2F1970&Email=testuserdude" + rand("1","1000") + rand("1","1000") + "@example.com&Password=123456&ConfirmPassword=123456";
        url         = "http://ipv4.fiddler/TokenBasedLoginTests/Account/Register";
        statuscode  = 302;
    }
    close
    {
        method      = ka;
    }
 }

Thanks

Matt

Matt Roberts
  • 26,371
  • 31
  • 103
  • 180

4 Answers4

4

Per http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx,

WCAT requests won't show up in Fiddler nor can a proxy server be used with WCAT.

The former part of that statement is implied by the latter part. It suggests that the WCAT team specifically removed the ability to use a proxy server, which seems like an odd choice, but might make sense if they thought the load would take down a proxy.

If you wanted, you could configure Fiddler to run as a reverse proxy, and then point WCAT at that reverse proxy; you'd see the traffic then, and Fiddler would redirect inbound requests to their actual destination. See http://www.fiddler2.com/redir/?id=reverseproxy

You might consider using the Visual Studio Web Test tools instead, as they do properly use the proxy (and hence Fiddler).

EricLaw
  • 56,563
  • 7
  • 151
  • 196
0

You could use an extension like this one http://blogs.iis.net/thomad/archive/2010/05/11/using-the-wcat-fiddler-extension-for-web-server-performance-tests.aspx

newtoallthis
  • 173
  • 6
  • That allows me to capture traffic and create WCAT scripts with it, but doesn't fix the issue of seeing WCAT-generated traffic in fiddler2 – Matt Roberts Aug 25 '10 at 13:51
0

What happens when you use the server of http://ipv4.fiddler? Local traffic doesn't go through Fiddler, but it adds the ipv4.fiddler as a proxy on top of wininet (I may be getting that wrong and Eric Lawrence will correct me, I'm sure), and as a result, can capture local traffic?

I use Fiddler quite a bit to test web apps and services and always use ipv4.fiddler to capture my local traffic.

Hope this helps!

David Hoerster
  • 28,421
  • 8
  • 67
  • 102
  • ipv4.fiddler is simply an alias for 127.0.0.1 which gets around the fact that many clients will not send traffic bound for "Localhost" to a proxy. He's not using the Localhost string, so he should see the traffic. – EricLaw Aug 26 '10 at 14:40
  • Cheers, but no joy. I've added "ipv4.fiddler to the transaction in wcat, like the sample shown in my original post edit. I called wcat with the server set to "ipv4.fiddler" but of course that fails because its not a server, so I was hopeful that my machine name combined with the ipv4.fiddler in the settings file would sort it, but no joy. – Matt Roberts Aug 26 '10 at 14:46
  • Sorry that didn't help. Eric's answer is it. – David Hoerster Aug 26 '10 at 14:57
0

You can easily track WCAT traffic (very useful for debugging) using a transport level tool (such as Wireshark or Ethereal) rather than an HTTP proxy. These tools are able to capture traffic at the network card/packet level. All you need to do is...

a) Run a capture with a filter enabled to limit to traffic between client(s) and server and using a particular protocol (i.e. HTTP) - There's always a lot of unrelated traffic flowing through your network card and adding the filtering will make things easier. If you have multiple clients it might be best to run the capture on the server.

b) Tracing a stream (normally just click on one of the packets related to the request / response and rebuild it to a request / response.

Note that this will impact on throughput/performance. Best to turn it off for a real run! Hope this is helpful!