httpclient在并发量较高的调用下问题如何去
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了httpclient在并发量较高的调用下问题如何去相关的知识,希望对你有一定的参考价值。
由于HttpClient内置支持HTTPBasic认证方式,因而使用HttpClient通过HTTPBasic认证的步骤显得较为简单。 1.为HttpClient的状态对象添加用户名/密码对。可以注意到在setCredentials方法中的另一个参数为AuthScope对象。事实上我们添加的每个用户名/密码对都与一个AuthScope对象相关联。AuthScope对象确定了此用户名/密码对的适用站点,在示例中所给出的用户名/密码对将只适用于位于80端口上的资源。HttpClient在与其他站点交互时将不会使用此用户名/密码对,这样有效地防止了机密数据被传送至不必要的站点。 2.开启HttpClient提供的占先式(Preemptive)认证功能。开启了这个功能后,HttpClient对于那些处在之前请求过的URI空间范围内的资源,会主动地随请求一起向服务器发送Basic认证数据,而不是等待服务器返回是否需要认证的响应后再提交认证。在多数情况下,能够减少请求-响应传递的次数,从而间接提高了服务器的响应能力。值得注意的是在这种情况下必须在AuthScope对象中明确指定适用站点,以避免向不相关的站点泄漏敏感数据。3.创建GetMethod对象,此对象将使用GET方式对保护资源发出HTTP请求。 4.setDoAuthentication(true)语句将告知HttpClient在服务器端发回需要认证的请求后,自动将我们在步骤1中设置的用户名/密码对发送至服务器,以完成认证过程。 5.执行GET请求,获取和处理受保护资源的内容。 参考技术A首先你要增加一个关于异步IO需要的包:
1、async-http-client包
2、log4j的包,这个不用我说了
3、slf4j-spi 的包,目前用1.5以上的版本比较多。
4、slf4j-log4j 的包,可以看出,slf4j是在log4j基础上包装的。
OK,就这几个了,弄好后再看看下面这段代码,通过使用它,性能可以得到明显改善:
[java] view plain
AsyncHttpClient client = new AsyncHttpClient();
try
Future<Response> f = client.prepareGet("http://www.google.com.hk/").execute();
System.out.println(f.get().getResponseBody("Big5"));//谷歌的输出编码集为Big5,反向解析结果的时候使用
catch(...) ....
这段代码是不是超级简单,可以通过上面描述的三种方式:
1、直接调用
2、将GetMethod或PostMethod对象作为共享对象反复使用。
3、使用AsyncHttpClient
这三种方法,非别使用一次调用、循环多次调用、并发调用来测试性能,后面两者的性能比第一种方法的性能要高很多。
生产环境如何快速跟踪分析定位问题-Java
我相信做技术的都会遇到过这样的问题,生产环境服务遇到宕机的情况下如何去分析问题?比如说JVM内存爆掉、CPU持续高位运行、线程被夯住或线程deadlocks,面对这样的问题,如何在生产环境第一时间跟踪分析与定位问题很关键。下来让我们看看通过如下步骤在第一时间分析问题。
CPU占用较高场景
收集当前CPU占用较高的线程信息,执行如下命令:
top -H -p PID -b -d 1 -n 1 > top.log
|
结果如下:
上图显示的都是某一个进程内的线程信息,找到cpu消耗最高的线程id,再配合jstack来分析耗cpu的代码位置,那如何分析呢?
先执行jstack获取线程信息
jstack -l PID > jstackl.log
|
将PID(29978)转成16进制:0x751a,16进制转换工具很多可以在线随便搜索一个或者基本功好的自己计算。
打开jstackl.log,查找nid=0x751a的信息,这样就定位到了具体的代码位置,这里由于是安全原因我就不贴图了。
通过上面的步骤就可以轻松的定位那个线程导致cpu过高,当然也可以通过其他方式来定位,下面介绍一个快捷的方式
#线程cpu占用
|
上述命令会以百分比的方式来显示每个线程的cpu消耗百分比,这里我就不贴图了,谁用谁知道。
内存消耗过高场景
收集当前活跃对象数据量信息,执行以下命令获取
jmap -histo:live pid > jmaplive.log
|
ps. jmap -histo:live 数据可以多进行几次,比如说间隔几分钟输出一次,然后对比两个文件的差异可以看出gc回收的对象,如果多次结果没有差异并且gc频繁执行,证明剩余对象在引用无法gc回收,这时就需要对服务进行限流给服务喘气的机会。
或者收集dump信息,通常这种获取方式需要较长时间执行,并产生大容量的dump文件,我们会考虑逐步废掉通过这个文件来分析。执行以下命令获取
jmap -dump:file=./dump.mdump pid
|
dump文件通过MAT工具来进行内存泄漏分析。
线程、内存分析工具
上面说过通过jstack生成的线程文件是可以通过工具来直接打开可视化分析的,这里我推荐使用:tda(Thread Dump Analyzer)这个工具可以自行搜索下载。
通过jmap -dump生成的dump文件也是可以通过工具来进行可视化分析的,这里我推荐使用MAT(Memory Analysis Tools)它可以通过eclipse plugin的方式使用或者独立的下载安装包使用。
以上是关于httpclient在并发量较高的调用下问题如何去的主要内容,如果未能解决你的问题,请参考以下文章
高并发场景下的 HttpClient 优化,QPS 大大提升!