为了提高httpwebrequest的执行效率,查到了一些如下设置

    request.ServicePoint.Expect100Continue = false;

    request.ServicePoint.UseNagleAlgorithm = false;
request.ServicePoint.ConnectionLimit = 65500;
request.AllowWriteStreamBuffering = false; request.Proxy = null; 然后就看到了如下相关的一些文章,记录下来: 转:C#中HttpWebRequest的GetRequestStream执行的效率太低,甚至偶尔死掉 用C#模拟网页登陆,其中去请求几个页面,会发起对应的http的请求request,其中keepAlive设置为true,提交请求后,然后会有对应的response: resp = (HttpWebResponse)req.GetResponse(); 之前的多次调试,一直都是可以正常获得对应的response,然后读取html页面的。 但是后来几次的调试,在没有改变代码的前提下,结果GetResponse却始终会超时死掉。 【解决过程】 1.默认request的timeout是1000000毫秒=100秒,都会超时,手动改为10秒,因此就更容易超时了,无法解决问题。 2.将http的request的keepAlive设置为false,问题依旧。 3.去参考:c# request.GetResponse();超时问题的解决,和HttpWebRequest多线程性能问题,请求超时的错误, 去把前面共4次的httprequest,每次都增加对应的: resp = null;
。。。
if (resp != null)
{
resp.Close();
}
if (req != null)
{
req.Abort();
} 结果还是没解决问题。 4. 同样参考:HttpWebRequest多线程性能问题,请求超时的错误, 去尝试关于DefaultConnectionLimit的设置,改为为10: System.Net.ServicePointManager.DefaultConnectionLimit = 10;
问题依旧。 5.又去测试了下,关于response.Close() 也是没解决问题。 6. 最后无意间,索性不抱希望的,再次DefaultConnectionLimit设置为更大的值50: System.NET.ServicePointManager.DefaultConnectionLimit = 50; 试了试,结果就解决超时的问题了。 然后才搞懂原因。 之前默认设置为2,后来改为10,都没有解决问题的原因在于,当前有很多个http的连接,没有被关闭掉, 而这些keepalive的连接,都是 由于代码中,对于前面多个request。其都是keepalive为true,以及多个response也没有close, 而之前调试了很多次了,所以,此时已经存在了很多个alive的http连接了,已经超过了10个了,所以前面设置了DefaultConnectionLimit 为10,也还是没用的。 而改为50,才够用。 【总结】 此处GetResponse超过的原因是,当前存在太多数目的alive的http连接(大于10个),所以再次提交同样的http的request,再去GetResponse,就会超时死掉。 解决办法就是,把DefaultConnectionLimit 设置为一个比较大一点的数值,此数值保证大于你当前已经存在的alive的http连接数即可。 【经验总结】 以后写http的request代码,如果不是必须的要keepalive的,那么就要设置KeepAlive为false: req.KeepAlive = false; 以及做对应的收尾动作: if (resp != null)
{
resp.Close();
}
if (req != null)
{
req.Abort();
} 【后记 2012-03-01】 又偶尔遇到一次,DefaultConnectionLimit已经是200了,足够大了,但是GetResponse和GetRequestStream,还是会超时死掉的问题,具体是什么原因导致的还不是很清楚,但是经过折腾,参考: HttpWebResponse’s GetResponse() hangs and timeouts 在: req = (HttpWebRequest)WebRequest.Create(constSkydriveUrl);
setCommonHttpReqPara(ref req);
resp = (HttpWebResponse)req.GetResponse(); 之前,添加一句垃圾回收: System.GC.Collect(); 然后就解决了GetResponse的超时问题,并且后面的GetRequestStream也同时可以正常工作,不超时了。 所以,看起来像是当前系统由于调试多次,并且HttpWebRequest和HttpWebResponse都是没有正常去Close的,可能会残留一些http的链接,然后就可能影响到了后续对于http的使用,垃圾回收后,估计就把残余的http相关资源释放了,然后http就可以正常工作了。 【总结】 对于GetResponse或GetRequestStream超时死掉的原因,可能是: 1.DefaultConnectionLimit是默认的2,而当前的Http的connection用完了,导致后续的GetResponse或GetRequestStream超时死掉 ==>> 默认系统只支持同时存在2个http的connection ==>> 使用HttpWebRequest之后如果没有close,则会占用1个http的connection,所以如果超过2次使用HttpWebRequest而没有close,那么就用完系统的http的connection,之后再去使用HttpWebRequest,GetResponse就会死掉 解决办法: 办法1: 每次使用完HttpWebRequest,使用 1
2
req.Close();
req=null;
去关闭对应的http connection 最好对应的HttpWebResponse也要close: 1
2
resp.Close();
resp
= null;
方法2: 修改DefaultConnectionLimit的值,改为足够大,比如: 1
System.Net.ServicePointManager.DefaultConnectionLimit
= 200; 2.系统中Http相关的资源没有正确释放,导致后续GetResponse或GetRequestStream超时死掉 就像我此处遇到的,可能是之前调用http相关函数,没有正确完全释放资源,导致虽然DefaultConnectionLimit给了足够大,但是还是会死掉,此时在http请求代码之前去做一次垃圾回收,则后续http的GetResponse或GetRequestStream就正常了,就不会超时死掉了。 参考代码如下: 1
2
3
4
5
System.GC.Collect(); req
= (HttpWebRequest)WebRequest.Create(constSkydriveUrl);
setCommonHttpReqPara(ref req);
resp
= (HttpWebResponse)req.GetResponse(); 3.Http的GET请求时,不要手动设置ContentLength的值 这个是参考这里:HttpWebRequest.GetResponse() hangs the second time it is called而记录于此的,也许有人是此原因,所以可供参考一下。 即Http的GET请求,不要添加类似如下的代码: 1
2
if (m_contentLength
> 0)
httpWebRequest.ContentLength
= m_contentLength;
不要去手动修改对应的ContentLength的值,C#的http相关库函数,会自动帮你计算的。 注:POST方法中,的确是要手动填充数据和算出数据大小,然后手动给ContentLength赋值的。 4.其他可能的一些原因 (1)关于KeepAlive的问题 如果Http的请求,是设置了KeepAlive=true的话,那么对应的http的connection会和服务器保持连接的。 所以如果上述办法都不能解决超时的问题,可以尝试将keepAlive设置为false试试,看看能否解决。 (2)关于Sleep 有些人好像是通过在http请求前,加了对应的Sleep,结果解决了此问题。需要的人,也可以试试。 (3)HttpWebRequest的Timeout 一般来说,既然超时了,往往是由于错误使用函数或者网络有问题导致的,所以实际上此处对于有些人去把HttpWebRequest的Timeout的值改的更大,往往都是没用的。 只不过,万一是由于网络响应慢而导致超时,那么倒是可以尝试,将HttpWebRequest的Timeout的值改为更大。 (其中HttpWebRequest的Timeout默认的值是100,000 milliseconds ==100 seconds)

  

C#中HttpWebRequest的GetRequestStream执行的效率太低,甚至偶尔死掉的更多相关文章

  1. 【转】C#中HttpWebRequest的GetRequestStream执行的效率太低,甚至偶尔死掉

    http://www.cnblogs.com/summer_adai/archive/2013/04/26/3045261.html

  2. GUI为什么不设计为多线程(用户事件和底层事件的流程是相反的,每层都加锁效率太低,共用一把锁那就是单线程)

    在我们这批新人转正评审的时候,我师父问了我的小伙伴一个问题:为什么一些更新界面的方法只能在主线程中调用?师父没有问我这个问题,让知其然但不知其所以然的我有种侥幸逃过一难的心情.我想如果回答那是因为An ...

  3. 老板说,Vim宏都不会用,你的工作效率太低啦~

    工作中,对于文本文件的编辑我们经常有这样的需求: 多次重复输入一段相同文本: 生成一段序列化的文本: 每行文本插入一句相同的文本. 除此之外,还有很多需要重复操作的动作.对于这些需求,如果我们人工去操 ...

  4. 在C代码中将结构体变量作为参数传递效率忒低

    在C语言编程中,我们几乎不可能看见有人将一个结构体变量作为参数进行传递,因为效率太低了.本文尝试从反汇编的角度给出其中的缘由. 对于C语言来说,所有的参数传递都是值传递.如果一个变量为指针,那么传递的 ...

  5. HttpWebRequest的GetResponse或GetRequestStream偶尔超时 + 总结各种超时死掉的可能和相应的解决办法

    [问题] 用C#模拟网页登陆,其中去请求几个页面,会发起对应的http的请求request,其中keepAlive设置为true,提交请求后,然后会有对应的response: resp = (Http ...

  6. iOS多线程中,队列和执行的排列组合结果分析

    本文是对以往学习的多线程中知识点的一个整理. 多线程中的队列有:串行队列,并发队列,全局队列,主队列. 执行的方法有:同步执行和异步执行.那么两两一组合会有哪些注意事项呢? 如果不是在董铂然博客园看到 ...

  7. SQL 中 SELECT 语句的执行顺序

    好像自已在书写 SQL 语句时由于不清楚各个关键字的执行顺序, 往往组织的 SQL 语句缺少很好的逻辑, 凭感觉 "拼凑" ( 不好意思, 如果您的 SQL 语句也经常 " ...

  8. 【转】C#中HttpWebRequest的用法详解

    本文实例讲述了C#中HttpWebRequest的用法.分享给大家供大家参考.具体如下: HttpWebRequest类主要利用HTTP 协议和服务器交互,通常是通过 GET 和 POST 两种方式来 ...

  9. 容易被忽略的事----sql语句中select语句的执行顺序

    关于Sql中Select语句的执行顺序,一直很少注意这个问题,对于关键字的使用也很随意,至于效率问题,因为表中的数据量都不是很大,所以也不是很在意. 今天在一次面试的时候自己见到了,感觉没一点的印象, ...

随机推荐

  1. P2261 [CQOI2007]余数求和

    我是题面 题意还是很清晰,很容易理解 1e9范围明显不能暴力,除非你能把常数优化到\(\frac1 {10}\),但我实在想象不到用了这么多取模怎么把常数优化下去 我们可以把\(k\%i\)变成\(k ...

  2. 015 反射中的 Class.forName() 与 ClassLoader.loadClass() 的区别

    作者:nnngu GitHub:https://github.com/nnngu 博客园:http://www.cnblogs.com/nnngu 简书:https://www.jianshu.com ...

  3. JVM类加载机制详解(二)类加载器与双亲委派模型

    在上一篇JVM类加载机制详解(一)JVM类加载过程中说到,类加载机制的第一个阶段加载做的工作有: 1.通过一个类的全限定名(包名与类名)来获取定义此类的二进制字节流(Class文件).而获取的方式,可 ...

  4. System Board Replacement Notice

    System Board Replacement Notice System Board Replacement Notice for TP 770E and TP 600 Restoring the ...

  5. python读取写入内存方法SringIO,BytesIO

    python中不仅仅可以在磁盘中写入文件,还允许直接在内存中直接写入数据:需要借助StringIO和BytesIO来实现: 1.直接操作StringIO from io import StringIO ...

  6. module.exports 、 exports 和 export 、 export default 、 import

    1:commonjs规范 module.exports={a:10,b:20} var test=require('lib/test') console.log(test.a);console.log ...

  7. 【IOI 2018】Werewolf 狼人

    虽然作为IOI的Day1T3,但其实不是一道很难的题,或者说这道题其实比较套路吧. 接下来讲解一下这个题的做法: 如果你做过NOI 2018的Day1T1,并且看懂了题面,那你很快就会联想到这道题,因 ...

  8. 洛谷 P4244 [SHOI2008]仙人掌图 II 解题报告

    P4244 [SHOI2008]仙人掌图 II 题目背景 题目这个II是和SHOI2006的仙人掌图区分的,bzoj没有. 但是实际上还是和bzoj1023是一个题目的. 题目描述 如果某个无向连通图 ...

  9. 洛谷 P2144 [FJOI2007]轮状病毒

    P2144 [FJOI2007]轮状病毒 题目描述 轮状病毒有很多变种.许多轮状病毒都是由一个轮状基产生.一个\(n\)轮状基由圆环上\(n\)个不同的基原子和圆心的一个核原子构成.\(2\)个原子之 ...

  10. 远程桌面(RDP)上的渗透测试技巧和防御

      0x00 前言 在本文中,我们将讨论四种情况下的远程桌面渗透测试技巧方法.通过这种攻击方式,我们试图获取攻击者如何在不同情况下攻击目标系统,以及管理员在激活RDP服务时来抵御攻击时应采取哪些主要的 ...