Tomcat作推送服務引出的對TCP協議的調優

背景

公司有個會議的產品，使用Tomcat的Comet做爲長鏈接推送服務，隨着產品的用戶量愈來愈大，出現了屢次無響應事件。

產品在Linux和Windows平臺上都有部署，可是Linux一直比較穩定，基本上是Windows出問題。並且公司的產品大多部署在銀行內部，因此沒法直接服務器檢查，由於這個問題一直頭疼了好一陣。

分析

公司的會議產品主要是用做iPad的推送服務器，猜想網絡很差的時候大量的iPad的產生異常的網絡鏈接阻塞了服務器。

檢查產品代碼發現是採用Tomcat官方推薦的Comet實現代碼，沒有發現問題。

經過jVisualVM等工具分析本地Tomcat的服務器鏈接池和內存溢出，沒有發現問題。

 

並且Linux下比較穩定，Windows容易出現問題，從這點猜想Linux平臺和Windows平臺的差別也是一個入口點，因此最大的懷疑對象就是網絡不穩定致使的相關問題。

重現

根據不斷的查找TCP相關協議，猜想客戶服務器那邊極可能出現了TIME_WAIT，CLOSE_WAIT的TCP鏈接異常（這點實在是苦逼啊，無法從客戶那邊的服務器取證。。。）

既然有了懷疑對象就好說了，驗證中......

既然網上的文章大都在講怎麼優化，那我這裏爲了驗證問題只能反着來了（實際上反證法無法很準去的驗證問題，由於多個異常的現象可能會同樣啊，不管如何實驗進行下去！）。

調整TcpTimedWaitDelay,MaxUserPort 參數

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]  "TcpTimedWaitDelay"=dword:0000001e
"MaxUserPort"= 20000

長時間的觀察中，未完待續。。。

 

參考資料

http://www.cnblogs.com/tianzhiliang/articles/2400176.html

http://blog.csdn.net/mhfh611/article/details/8769617

http://blog.csdn.net/shootyou/article/details/6622226

http://blog.csdn.net/zdwzzu2006/article/details/7716904