放翁(文初)的一亩三分地

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  112 随笔 :: 1 文章 :: 320 评论 :: 0 Trackbacks
 

目标:

         根据四方面的配置调整,观察SIP5.5在高并发下的性能情况。

         由于SIP接收的请求都是服务型处理请求,因此认为Apache+Jboss只会带来多余的转发损耗,所以正好这次也作一个验证,看看Apache+JBoss是否不适合于这种纯动态服务请求的情况。 
        四方面环境比较:

1. JBoss APR模式与Http1.1模式性能差异。(确切来说应该是JBoss内置Tomcat采用APR的情况)。

2. 是否采用Apache+JBossApache不同的转发模块带来的性能差异。

3. Memcached Client版本优化后对性能影响。

4. ISP有不同延时对于SIP的性能影响。

前置条件:

SIP版本5.5,并发用户600ISP默认耗时20msApache配置和JBoss WebContainer配置,一些优化配置参见附加信息。

最终结果:

       SIP采用Apache(Mod_jk)+JBoss(APR)+Cache2.4.2,具体配置参见附加信息。

测试结果表格:

       详细的测试报告可以参看:http://spreadsheets.google.com/pub?key=pcsQ9Wm01cIEjjQcistPNDg

JBoss配置差异测试比较:

 

Apache(2.0.52)配置

JBoss(4.2.1)配置

Cache Client Version

TPS

TPS区间

APR

2.4.2

1705

1600-1900

HTTP1.1

2.4.2

1615

1550-1700

Mod_jk(1.2.27)

HTTP1.1

2.4.2

2090

1800-2800

Mod_jk(1.2.27)

APR

2.4.2

3223

3200-3400

补充:

         配置成为Http1.1模式的两种情况下,测试结果TPS波动频率很高,在Mod_jk模式下波动幅度也很大。

1.         可以证实在非APR模式和高并发的情况下Web容器处理请求能力不稳定,同时也直接影响到了SIP的性能。

2.         在测试中发现不采用APR模式的情况下,Web容器会消耗大量的socket连接通道。

Apache模块差异测试比较:

 

Apache(2.0.52)配置

JBoss(4.2.1)配置

Cache Client Version

TPS

TPS区间

APR

2.4.2

1705

1600-1900

Mod_jk(1.2.27)

APR

2.4.2

3223

3200-3400

Weblogic.so

APR

2.4.2

1033

350-1400

补充:

         Weblogic.so模块是以前系统遗留的http请求转发模块。在测试过程中Weblogic模块的测试中波动频率和幅度都很大。根据测试结果可以看出:

1.       APR模式下,Apache+JBoss对于SIP这种无静态资源访问,纯API性质的服务来说依旧会有比较好的优化效果,特别是在接受请求环节。(不论是TPS还是TPS波动区间和频率都有很好的表现)

2.       Weblogic.so这个模块性能绝对不行,稳定性极差。

Cache客户端版本差异测试比较:

 

Apache(2.0.52)配置

JBoss(4.2.1)配置

Cache Client Version

TPS

TPS区间

APR

2.4.2

1705

1600-1900

APR

2.4

1615

1550-1700

Mod_jk(1.2.27)

APR

2.4.2

3223

3200-3400

Mod_jk(1.2.27)

APR

2.4

2485

2650-2800

补充:

         2.4.22.4版本在单独测试的环境下:500并发用户,每个并发用户1000getset,性能相差40%左右。

         上面测试结果可以看出:

1.    在无apache时,性能有所提升,但不明显,而在有apache时,性能大幅提升,证明在无apache的情况下,memcache客户端已经不是性能瓶颈,因此替换版本效果不大,在http请求处理性能大幅提升的情况下,memcache客户端性能优化的优势就得到了体现。

2.    在测试中也发现Apache + JBoss波动频率和区间都小于其他几个测试情况,图形十分平稳,证明处理请求不是系统瓶颈。

ISP响应时间差异测试比较:

 

Apache(2.0.52)配置

JBoss(4.2.1)配置

Cache Client Version

ISP响应时间(ms)

TPS

TPS区间

Mod_jk(1.2.27)

APR

2.4.2

20

3223

3200-3400

Mod_jk(1.2.27)

APR

2.4.2

110

Mod_jk(1.2.27)

APR

2.4.2

900

测试优化总结:

1. 不要认为内存使用无关性能。现在很对开发者认为内存申请分配是由gvm来管理,但是内存是否合理使用很可能会影响互联网应用的高并发下性能。GC带来的系统短暂停滞会在高并发下影响性能。

2. 使用java的方法需要有足够的“理由”和“度”。Java1.5以后对concurrent方面做了很不错的支持,但是这些并发处理毕竟会消耗资源,因此在能够避免频繁使用的情况下尽量优化流程。在一些简单的场景下,是否有必要使用一些比较耗时的方法,例如split,用起来很方便,但是在设计底层通信操作的时候还是分秒必争(JProfiler看看消耗的时间占用的比例以及调用的次数),用一些自己简单的方式替换。

3. 眼见未必为实,测试才得真知。在SIP5.5中考虑连接后端ISP方式由HttpURLConnection替换成为HttpClient,感觉HttpClient的开发模式更加容易认为是共享传输通道(Get,Post都单独作为包来交由HttpClient单个实例),虽然看到HttpURLConnection说明中提到会共享通道。结果一压,HttpClient根本上不去,原因是构建这些Get,Post本身也很耗时,同时HttpURLConnection底层共享优化的也很不错。HttpClient的优势还是在于去构建简单的客户端,能够处理附加cookies等额外需求。

4. 链式处理的情况下,上下文中共享信息减少数据频繁访问缓存。

5. 操作系统配置以及Web容器的配置会直接影响应用的性能,特别是一些Socket交互比较频繁,会有很大并发的应用。具体的配置可以参见最后的说明。

6. APR模式对于服务器处理能力有很大的影响,EpollUnix socket都会来带很大的性能提高(降低资源消耗)。

7. 在过去谈过异步Servlet的方式(Servlet3.0的特性之一),但是JBoss5测试下来看,稳定性并不好,并且可能会有一些并发问题。

8. 先列出性能瓶颈可能点,然后分别对已经优化的模块进行单独测试,最后整合并且通过多场景测试来验证优化结果。


附加信息:

JBoss Web Container配置:

<Connector port="8128" address="${jboss.bind.address}"   

         maxThreads="1024" maxHttpHeaderSize="8192"

         emptySessionPath="true" protocol="HTTP/1.1"

         enableLookups="false" redirectPort="8443" acceptCount="1024"

         connectionTimeout="20000" disableUploadTimeout="true" useBodyEncodingForURI="true"/>

Apache work的配置:

Keep alive off

<IfModule worker.c>

ServerLimit          80

ThreadLimit          128

StartServers         10

MaxClients           8000

MinSpareThreads      64

MaxSpareThreads      800

ThreadsPerChild      100

MaxRequestsPerChild 10000

</IfModule>

Linux配置信息:

执行:vi /etc/sysctl.conf   

添加一行:net.ipv4.ip_local_port_range = 1024 65535

       再执行:sysctl -p

         更改ulimit –n属性,可用端口数,还有ip_conntrack_max 

APR

       Tomcat优化了IO(sendfile,epoll,OpenSSL)。操作系统的一些函数(随机数的产生,系统状态的获取等),本地进程优化(共享内存,NT的管道,UnixSocket)Tomcat有配置监听器直接会检测APR模块是否存在,在bin目录下建立native目录,并且放置对应的so或则dll即可。

posted on 2009-03-03 20:14 岑文初 阅读(1760) 评论(2)  编辑  收藏

评论

# re: 服务集成平台性能测试与优化(应用与环境) 2009-03-05 18:11 most
每个 HttpURLConnection 实例都可用于生成单个请求,但是其他实例可以透明地共享连接到 HTTP 服务器的基础网络.不是很明白  回复  更多评论
  

# re: 服务集成平台性能测试与优化(应用与环境) 2009-03-05 23:04 lizongbo
我曾经以为优化hessian为tcp版本可以提升性能,但是后来阅读了jdk的sun.net.www.http.HttpClient.java的代码才发现,sun的HttpURLConnection是已经实现了keepalive特性的,且缓存的是最大10连接,在性能上已经优化的很不错了:

http://618119.com/archives/2009/01/11/126.html
  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: