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

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