简体   繁体   English

为什么在使用Fiddler时HttpWebRequest对象的性能会提高?

[英]Why does the performance of the HttpWebRequest object improve while using Fiddler?

I'm getting some very strange behaviour with HttpWebRequest I hope someone can help me with. 我正在使用HttpWebRequest获得一些非常奇怪的行为我希望有人可以帮助我。 I have a console app which does some aggregation work by by using the HttpWebRequest object to retrieve the contents of a target website. 我有一个控制台应用程序,它通过使用HttpWebRequest对象来检索目标网站的内容来完成一些聚合工作。 Due to the nature of the requirement the app is multithreaded and attempts to make anywhere between 10 and 30 simultaneous connections (I've been experimenting with a range of values). 由于要求的性质,应用程序是多线程的,并尝试在10到30个同时连接之间进行任何操作(我一直在尝试一系列值)。 The actual web request is structured as follows: 实际的Web请求结构如下:

var req = (HttpWebRequest)WebRequest.Create(url);
WebResponse resp = req.GetResponse();
Stream s = resp.GetResponseStream();
var sr = new StreamReader(s, Encoding.ASCII);
string doc = sr.ReadToEnd();
sr.Close();
resp.Close();
return doc;

Anyway, the strange behaviour is that under normal circumstances the app is achieving around 120 requests per minute but if I open up Fiddler it jumps to about 600. Using Windows 7 Resource Monitor I can see the network activity increase accordingly. 无论如何,奇怪的行为是在正常情况下应用程序每分钟实现大约120个请求但是如果我打开Fiddler它会跳到大约600.使用Windows 7资源监视器我可以看到网络活动相应增加。 The TCP connections for the console process now list the remote address as "IPv4 loopback" rather than the target server IP address (expected). 控制台进程的TCP连接现在将远程地址列为“IPv4环回”而不是目标服务器IP地址(预期)。 I did wonder about the max number of simultaneous HTTP requests allowed by the machine but changing this in the registry does not seem to make a difference. 我确实想知道机器允许的最大同时HTTP请求数,但在注册表中更改这个请求似乎没有什么区别。

So the question is; 所以问题是; what is it about running Fiddler which suddenly increases the throughput five-fold and how can I achieve this natively on the machine without needing to launch another tool? 什么是运行Fiddler突然增加了五倍的吞吐量,我怎么能在机器上本地实现这一点,而无需启动另一个工具?

Thanks! 谢谢!

Looks like I've now been able to get the throughput right up (to double that I was getting with Fiddler open actually) by setting the max connections in the App.config: 看起来我现在已经能够通过在App.config中设置最大连接来获得吞吐量(通过实际打开Fiddler得到的两倍):

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="30" />
  </connectionManagement>
</system.net>

Very happy with the result but am still a little mystified as to why having Fiddler open changed the results so dramatically. 对结果非常满意,但是为什么Fiddler打开会如此戏剧性地改变结果仍然有点神秘。

One thing I noticed right away is that you are not implementing using blocks. 我立即注意到的一件事是你没有使用块实现。 That adds a randomness factor that might be multiplied by the number of requests, so I suggest you fix that: 这会增加一个可能乘以请求数的随机因素,所以我建议您修复:

var req = WebRequest.Create(url);
using (WebResponse resp = req.GetResponse())
{
    using (Stream s = resp.GetResponseStream())
    {
        using (var sr = new StreamReader(s, Encoding.ASCII))
        {
            return sr.ReadToEnd();
        }
    }
}

Next, FYI, Fiddler acts as a proxy. 接下来,FYI,Fiddler充当代理人。 If your default proxy was set up to use a script to set up the proxy configuration, then I wonder whether having Fiddler running might not remove the time necessary to do the script setup. 如果您的默认代理设置为使用脚本来设置代理配置,那么我想知道运行Fiddler是否可能无法删除执行脚本设置所需的时间。 That might happen only once, rather than on each request. 这可能只发生一次,而不是每次请求。

I had a problem similar to yours and wanted to share my resolution. 我有一个类似于你的问题,想分享我的决议。

In short, I had a console program that was making HTTP requests and would, after 15 minutes or so, timeout. 简而言之,我有一个控制台程序正在发出HTTP请求,并且在15分钟左右后会超时。 However, if I used Fiddler then I never experienced timeouts, even after having it run for days straight. 但是,如果我使用Fiddler,那么我从未经历过超时,即使它连续运行了几天。

I tried setting the maxconnections property in App.config, but that didn't seem to help at all. 我尝试在App.config中设置maxconnections属性,但这似乎没有任何帮助。 I then went in and each and every reference to HttpWebRequest, HttpWebResponse, and the stream objects used to read/write data to these objects within using blocks. 然后我进入了每个引用HttpWebRequest,HttpWebResponse和用于在使用块内读/写数据到这些对象的流对象。

That seems to have done the trick. 似乎已经成功了。 I've been running for almost 24 hours now without a timeout and without Fiddler running. 我已经跑了将近24小时,没有超时而且没有Fiddler跑。

For me, I was setting request.ProtocolVersion = HttpVersion.Version10; 对我来说,我正在设置request.ProtocolVersion = HttpVersion.Version10;

The default setting for this is HttpVersion.Version11. 默认设置是HttpVersion.Version11。 When I set this back to the default my requests went much faster without fiddler. 当我将其设置回默认值时,我的请求在没有fiddler的情况下变得更快。

I hope this helps someone else, it's taken me all morning to figure this out! 我希望这可以帮助别人,我整个上午都把它弄清楚了!

The way you query causes to create a new session for each call, which is overhead, it could be that fiddler adds session to your queries.... 您查询的方式导致为每个调用创建一个新会话,这是开销,可能是fiddler将会话添加到您的查询....

try 尝试

private static CookieContainer _cookieContainer = new CookieContainer(); private static CookieContainer _cookieContainer = new CookieContainer();

_httpWebRequest.CookieContainer = _cookieContainer; _httpWebRequest.CookieContainer = _cookieContainer; //with recycling the cookiecontainer //回收cookiecontainer

We had the same issue, set your httpWebRequest.PreAuthenticate to true. 我们遇到了同样的问题,将您的httpWebRequest.PreAuthenticate设置为true。

you should not have 401 response anymore, so you'll open less connections... 你不应该再有401响应,所以你会打开更少的连接......

I had the same problem. 我有同样的问题。 I downloaded this: http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html It was the reason of performance of the HttpWebRequest. 我下载了这个: http//www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html这是HttpWebRequest性能的原因。 It modifies TCPAckFrequency and totally mess up everything. 它修改了TCPAckFrequency并完全搞乱了一切。 I removed it and now IT WORKS. 我删除它,现在它工作。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM