idserver jboss tunning

6月13日升级，做了两点性能调整：

A、构架方案从Jboss直接连接f5并处理https请求，切换到apache连接f5，并处理https请求，jboss通过AJP协议连接apache

B、优化URLConnection连接代码，连接idstorage时重用http长连接。（以前每次连接idstorage，需要重新开启socket）(keep-alive request number 可以在server.xml中设置，默认为100次连接后，断开socket，可以设置为-1）

线上jboss比较：

	升级前	升级后
信息获取时间点	6月12日	6月17日
线上服务运行时间	18天	3天
抽样机器地址	OAuth3	OAuth3
内存占用大小（注a）	1549M	130M
垃圾回收占用时间（注b）	21925秒 = 1%的运行时间	35秒 占0.01%运行时间
与Idstorage服务的socket连接数量	154（注c）	7
超过1秒的jboss请求访问数(注d)	877（总共日志61W行）	196（总共日志30W行）
超过1秒的idstorage请求	19	2

注a：这里的内存大小，是通过jmap统计的内存中对象大小总和值。而不是top中的内存值。

注b：通过jstat –gcutil pid得出。命令可查看当前jvm各个区占用内存大小，各个区的回收次数和回收时间。

升级前jboss的内存分析：

S0S1 E OP YGC YGCTFGC FGCT GCT

0.000.00 27.93 82.89 50.45 92965 1907 16200420017 21925

从上面的数据看出，O=82.89代表内存中的老生命对象已经占用了1.7G old区的大部分，已经不够用了，因此做了16W次old区的full gc，而full gc是非常耗时的，结果就是cpu花在gc上的时间很多。

升级后jboss内存分析：

S0S1 E OP YGC YGCTFGC FGCT GCT

0.000.00 5.69 4.44 49.005134 32.784 52.796 35.580

从上面数据可以看出，O=4.44，内存占用非常小，而full gc才做了5次，因此jboss的整体gc负担非常轻。

注c：154个中包括因为换socket后，原先断开的socket状态变为TIME_WAIT。所以不代表当前有154个idstorage socket连接。

注d：

升级前877个resp slow分部：

92 /innerapi/oauth/access_token_cap

233 /innerapi/oauth/access_token_xauth_yunos_open （这个因为rsa解密本来就慢）

56 /openapi/id/aliyunid

371/scripts/jquery-1.5.2.min.js

其它省略

升级后196个resp slow分布：

9 /innerapi/id/aliyunid_cookie

9 /innerapi/oauth/access_token_xauth_mobile_alipay

162/innerapi/oauth/access_token_xauth_yunos_open（这个因为rsa解密本来就慢）

5 /login/check_need_captcha_code.htm

其它省略

1、jboss自带的connector去处理https请求，会很吃内存

从下面的数据可以看出，jboss处理https后，内存中大头都是跟https处理有关的java类。使用apache处理https，jboss走ajp后，那些top10中跟https有关的java类一下子全部消失了。

使用jboss处理https后，内存top10：

num#instances #bytes class name

----------------------------------------------

1: 1822210 262398240com.sun.net.ssl.internal.ssl.SSLSessionImpl

2: 4019327 261938120[B

3: 1934867 216756080[Ljava.util.Hashtable$Entry;

4: 2211842 123863152java.lang.ref.SoftReference

5: 1934789 123826496java.util.Hashtable

6: 1975065 116832368[C

7: 1823220 116686080java.lang.ref.Finalizer

8: 2209820 106071360sun.misc.CacheEntry

9: 2008420 80336800java.lang.String

10: 1822212 58310800[Ljava.security.cert.X509Certificate;

使用apache处理https，jboss走AJP协议，内存top10：

num#instances #bytesclass name

----------------------------------------------

1: 102839 14294832[C

2: 91504 13474952<constMethodKlass>

3: 91504 10993376<methodKlass>

4: 8321 9818256<constantPoolKlass>

5: 20663 8170376[Ljava.lang.Object;

6: 143119 7296656<symbolKlass>

7: 14708 6795360[B

8: 8321 6587904<instanceKlassKlass>

9: 7099 5881120<constantPoolCacheKlass>

10: 139130 5565200java.lang.String

11: 14792 5107400[I

12: 78727 5038528java.util.TreeMap$Entry

13: 15604 2851728[Ljava.util.HashMap$Entry;

14: 17245 2621240java.lang.reflect.Method

15: 4056 2394520<methodDataKlass>

16: 38105 1829040java.util.HashMap$Entry

17: 8965 1649560java.lang.Class

2、jboss处理https的对象，都会跑到old区。

在测试平台，尝试以：

-Xmx2g -Xms2g -Xmn1g -XX:+UseParNewGC-XX:+UseConcMarkSweepGC

试图将new区放大到1g，看看相关垃圾是否会在newgc中处理掉，因为newgc的处理比较快，这样变相减轻了jboss负担。

跑了8个小时后，结果是：

S0S1 E OP YGC YGCTFGC FGCT GCT

0.0043.20 9.4299.64 40.181226 58.384 2436 974.099 1032.483

O = 99.64，意味着1g的old区已经完全不够用了，于是8小时内发生了4千多次fullgc，jboss总内存达到1160M。

没有达到在newgc中将其回收的目的。

如下为对比数据

	总共内存2g，old区1g	总共内存2g，old区1.7g
运行时间	12小时	12小时
内存占用	1160M	1744M
Gc时间	5453秒（其中fullgc4912次，5394秒）	220秒
超过1秒请求数	10685	1355

3、通过jboss native模块，使用APRConnecotr，jboss可直接处理https请求

Jboss native模块，其实是对apr本地lib的一个java包装，通过这个技术，java类中可以调用本地aprlib接口，处理ssl和网络请求，最终通过openssl处理https，这样和apache处理https一样了。

通过这种方法，可以让jboss直接走f5，直接处理https，且内存占用也很小。

跑了1天半时间下，jboss内存状态：

S0S1 E OP YGC YGCTFGC FGCT GCT

29.360.00 31.96 12.5030.51 8150 104.400 265.235 109.636

总共内存大小264M，这样jboss的负担也很轻。

缺点：jboss native不是jboss自带的模块，需要额外安装，不是很方便维护。

4、jboss直接走http通道，效率也很高

	Jboss http connector	Jboss https connector
运行时间	8小时	8小时
内存占用	118M	1.1G
Gc时间	14秒	1032秒
超过1秒的请求数	239	3708