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

youxinrencwx

浏览: 71537 次
性别:
来自: 北京

最近访客更多访客>>

hlyhexiansheng

www083250266

wangqiaowqo

iluoxuan

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

目标：

根据四方面的配置调整，观察SIP5.5（服务集成平台）在高并发下的性能情况。

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

四方面环境比较：

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

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

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

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

前置条件：

SIP版本5.5，并发用户600，ISP默认耗时20ms，Apache配置和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.2和2.4版本在单独测试的环境下：500并发用户，每个并发用户1000次get和set，性能相差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的方法需要有足够的“理由”和“度”。Java在1.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模式对于服务器处理能力有很大的影响，Epoll和Unix 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

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的管道，Unix的Socket)。Tomcat有配置监听器直接会检测APR模块是否存在，在bin目录下建立native目录，并且放置对应的so或则dll即可。