`
omygege
  • 浏览: 1345425 次
文章分类
社区版块
存档分类
最新评论

服务集成平台性能测试与优化(应用与环境)

 
阅读更多

目标:

根据四方面的配置调整,观察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即可。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics