首先是TimeOut问题,不仅仅是在高并发场景下,实际项目中建议不管是任何场景都要设置它的值.在HttpWebRequest对象中,它的默认值是100000毫秒,也就是100秒.如果服务端出现问题,默认设置将会造成严重阻塞,对于普通项目也会严重影响用户体验.返回失败让用户重试也比这样长时间等待体验要好.
ReadWriteTimeout很多朋友可能没有接触过这个属性,尤其是使用.net 4.5里HttpClient对象的朋友.有过Socket编程经验的朋友可能会知道,socket连接有连接超时时间和传输超时时间,这里的ReadWriteTimeout类似于Socket编程里的传输超时时间.从字面意思上看,就是读写超时时间,防止数据量过大或者网络问题导致流传入很长时间都无法完成.当然在一般场景下大家可以完全不理会它,如果由于网络原因造成读写超时也很有可能造成连接超时.这里之所以设置这个值是由于实际业务场景决定的.大家可能已经看到,以上代码对于ReadWriteTimeout的设置并不像Timeout一样设置为一个固定值,而是放在了一个Const类中,它实际上是读取一个配置,根据配置动态决定值的大小.实际中的场景是这样的,由于压测环境无法完全模拟真实的用户访问场景.压测的时候都是使用单个单号进行轨迹查询,但是实际业务中允许用户一次请求查询最多多达数百个单号.一个单号的轨迹记录一般都是几十KB大小,如果请求的单号数量过多数量量就会极大增加长,查询时间和传输时间都会极大增加,为了保证双11期间大多数用户能正常访问,必要时会把这个时间设置的很小(默认是3000毫秒),让单次查询量大的用户快速失败.
以上只是一种备用方案,不得不承认,既然系统允许一次查询多个单号,因此在用户在没有达到上限之前所有的请求都是合法的,也是应该予以支持的,因此以上做法实际上有损用户体验的,然而系统的资源是有限的,要必要的时候只能牺牲特殊用户的利益,保证绝大多数用户的利益.双11已经渡过,实际中双11也没有改动以上配置的值,但是做为风险防范增加动态配置是必要的.
这里再多差一下嘴,就是关于ContentLength它的值是可以不设置的,不设置时程序会自动计算,但是设置的时候一定要设置字节数组的长度,而不是字符串的长度,因为包含中文时,根据编码规则的不同,中文字符可能占用两个字节或者更长字节长度.
关于 request.ServicePoint.Expect100Continue = false; request.ServicePoint.UseNagleAlgorithm = false;这两项笔者也不是特别清楚,看了相关文档也没有特别明白,还请了解的朋友指点,大家共同学习进步.
request.ServicePoint.ConnectionLimit = 2000是设置最大的连接数,不少朋友是把这个数值设置为65536,实际上单台服务器web并发连接远太不到这个数值.这里根据项目的实际情况,设置为2000.以防止处理能力不足时,请求队列过长.
request.AllowWriteStreamBuffering = false;根据[微软文档()]这个选项设置为true时,数据将缓冲到内存中，以便在重定向或身份验证请求时可以重新发送数据.
最为重要的是,文档中说将 AllowWriteStreamBuffering 设置为 true 可能会在上传大型数据集时导致性能问题，因为数据缓冲区可能会使用所有可用内存。由于发送的请求仅仅是单号,数据量很小,并且很少有用户一个单号反复查询的需求.加上可能会有副作用.这里设置为false.
request.Proxy = null;这里是参考了一个一位网友的文章,里面提到默认的Proxy导致超时怪异行为.由于解决问题是在10月份,据写这篇文章已经有一段时间了,因此再寻找时便找不到这篇文章了.有兴趣的朋友可以自己搜索一下.
很多朋友可能会关心,通过以上配置到底有没有解决问题.实际中以上配置后已经经历了双11峰值qps过万的考验.下面给出写本文时候请求耗时的监控
可能看了这个图,有些朋友还是会有疑问,通过上面日志截图可以看到,除了耗时在100ms以上的请求外,普通的耗时在四五十毫秒的还是有很多的,但是下面这个截图里都是在10到20区间浮动,最高的也就30ms.这其实是由于在压测的过程中,发现Hbase本身也有不稳定的因素(大部分请求响应耗时都很平稳,但是偶尔会有个别请求娄千甚至数万毫秒(在监控图上表现为一个很突兀的线,一般习惯称为毛刺),这在高并发场景下是不能接受的,问题反馈以后阿里云对Hbase进行了优化,优化以后耗时也有所下降.)