目標：
根據四方面的配置調整，觀察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即可。
