1.筆者本人現在在一家創業公司擔當整個平台架構的角色，而這家公司是做一移動網際網路相關的一些應用產品，由其現在正在和中國最大的網際網路公司之一進行合作，負責該網際網路公司的手機終端的長連線推送服務，所以有一些總結特在此和大家分享一下。
1) 單jvm實現了50w以上長連線，每秒訊息處理「hello word」和心跳包6w次
2）該長連線，不僅實現了手機終端的摸擬，而且該框架也是乙個成熟的rpc框架，已經在筆者所在的公司使用。比阿里巴巴開源版本出來的"dubbo"效能要高，而且更節省頻寬，大家可以測試比較一下。
3）因為netty支援的長連線，每條連線占有用記憶體是5k，筆者經過包裝之後每條連線占用5.3k， 每條長連線系統要占用8k；所以大家可以計算一下每條長連線一共要消耗的系統記憶體量。
4）通過「3）」我們可以計算，50w長連線需要多少記憶體量（jvm）：500000*5.3k=2650000k=2.53g，50w長連線需要多少記憶體量（os）：500000*8k=3.8g
3.好了，說了這麼多，看看筆者的一些測試資料吧（筆者只是把幾個月前的測試郵件內容發出，因為某些原因筆者不能發出現在公司正在使用的完全**實現）
1）如果要支援這麼多的長連線，一定要修改一下系統的一些核心引數，如下：
c**
vi /etc/sysctl.conf
net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog = 32768
net.core.somaxconn = 32768
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_tw_recycle = 1
#net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800
#net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 120
net.ipv4.ip_local_port_range = 1024 65535
/sbin/sysctl -p
最後個命令是讓配置生效的。
vi /etc/security/limits.conf
新增
* - nofile 1006154
注：a.因為移動終端經常會因為網路問題斷開，所以要修改核心引數支援連線斷開後快速**
b.os雖然預設tcp的緩衝記憶體已經足夠大，但是因為系統要支援很多的長連線，所以緩衝記憶體還需要調整，要不然會發生丟包情況（這個也是筆者當時和58同城的資深vp聊天的時候了解並學習到的）
c.檔案控制代碼數要加大，因為os預設支援的長連線數量比較小
2）下面是測試的郵件正文
寫道1. 有訊息收發之間的間隔，比如說。client --> server端發訊息。
如果server端預設1分鐘沒有收到訊息（包括心跳），則斷開連線，可配間隔時間。
同理，如果client端沒有server推過來的訊息（包括心跳），則斷開連線，可配間隔時間。
當然，如果沒有訊息，心跳包也是可以client server互發的。如果沒有訊息，心跳就會互發，為了保證長連線不斷。如果要是在接收方沒有訊息過來，則認為連線斷了。之前設計這個的時候，就是考慮到了手機端的長連線的各種應用場景。
2. 每個登入使用者沒有使用者session，不過有這個介面，可以每個連線可以新增乙個attchment，可以跟據連線繫結資訊。
測試的時候沒有給attchment加資訊。
其實真的不是為了代替他的方案，當時設計的時候就是為了rpc和手機服務端長連線設計的。
使用者session資訊比較占用記憶體，我是建議使用者session資訊放在堆外，這樣不影響jvm。
3. 現在記憶體表現是用的cms**策略，所以沒有出現full gc**停頓的情況。但是因為netty的長連線本身就佔了5k，而且我們這邊又加了一些擴充套件資訊，所以現在乙個連線佔了5.3k。
4. 為什麼說現在超過50w了，是因為現在記憶體上限設成6g了，然後又進行了50w以上的長連線和每秒60000以上的訊息傳送（hello word）。
年輕代和老年代**的時間都在0.4秒左右，所以對應用沒有影響才敢說50w長連線了。
（注：年輕代**，其實整個應用會停的，老年代的 full gc也是整個應用會停的；不過gc.log我看了，在0.4秒左右，所以沒有影響應用）
（其實理論上還可以加記憶體，不過沒有經過壓力測試也沒有時間弄了，沒有測試機測試一回太累了，不過至少保證50w長連線沒有啥問題）
（我估計也差不多了是上限了，應用記憶體**已經佔了0.4秒了，再加大如果**時間占有的太長也不好）
5. 之前為什麼說加到6g測試後，不行。是因為我發現jvm的年輕代不能開太大，好像年輕代開的太大會影響整個應用的停頓時間。所以這次是把年輕代保持不變，heap推放大到6g，所就是說多出來的2g空間給老年代了。而長連線正好在老年代儲存，所以新加的2g給長連線正好把長連線推到了50w長連線。而且還有1g以上的空閒空間，而且老年代的full gc也控制在了0.4秒，我感覺比例正好。
下面是測試資料：
2. jvm 引數配置：
3. 資源使用情況：
5. 每秒訊息數：60000msg/s
6. gc.log 資訊如下：
gc[yg occupancy] 這一段是老年代full gc ：會讓整個應用停止，real 是真實時間，0.42
因為gc 新年代和老年代收回不頻繁，所以對應用沒有影響。記憶體我也其實也不想再加了，在60000 個訊息併發和50w 心跳包的情況下能做到這個效果，我感覺不錯了。
剛才問了手機qq 的長連線，這前他們是15~20w 長連線一台，現在新的架構也就能做35~40w ，我感覺現在應該行了。
summercool-hsf框架位址（已經在某些公司的大型應用成熟使用1年時間）：
移動網際網路行業
1.手機 平板案公司及其運營商 高通方案公司及運營商 沃特沃德 聞泰 同洲 輝燁 東方拓宇 海信 優電 天瓏 賽博宇華 豪成 中科創達等等。mtk方案公司及運營商 tcl 機甲 鼎智 鼎為 酷派 銳嘉科 海派 華勤 龍旗 波導 聞尚 華粵世通 金科龍 倍易通 鼎維爾 致遠 華立德 鴻宇 國通世紀 豪...
網際網路 移動網際網路小團隊創業1
本文特定針對於網際網路 移動網際網路小團隊創業，創新工場汪華。找到乙個足夠大，快速增長，還處於相對早期的大方向，創業要順勢而為，太小太窄，太早太晚的都不合適。找個你真正熟悉了解信任的人搭伙建團隊。創業是個艱難的過程，才認識1 2 天的人哪怕相談甚歡，也最好先花足夠長的時間先加深了解，建立信任。乙個人...
移動網際網路的明天
明天一定是屬於移動網際網路的，這點已越來越不容否定。在移動網際網路到來的時候，能夠做點什麼呢？一點不成熟的想法，簡單記錄之。門戶，讓每個用移動終端裝置的人，不論是iphone，android這樣的智慧型手機，還是ipad，平板，抑或是webos，google，megoo的上網本，他們開啟裝置後第乙個...