前言：新項目上線，考驗高併發，預選使用LR錄製腳本跑腳本，考慮到搭建，使用簡便的jmeter工具， 來跑500、1000、1500、2000的併發並打出報告，中間經歷過tomcat與jmeter優化。
高併發下考慮的層面 系統 + nginx(理論3W左右) + tomcat--- 標籤（tcp）
實際操作：
1、
方案：2000個線程，採取並大（可以選擇單個線程間隔），錯誤日誌實時打印
當併發量達到1740時候，出現報錯，報錯日誌在附件jmeter.txt.
此時服務器，cpu佔用量爲2.5% 高於平時1.5%-2%，
Memcache大概多消耗1.4G-2G之間。
Tcp連接數監控 從150左右飆升至2400左右，無影響
此時：服務器情況良 好
另：tcp連接超過3000時候（昨天測試接口4700併發）。出現cpu報警，開始優化架構
開始排查：
發現報錯，不是服務端報錯，是不是jmeter工具內存飆高，發現自己pc內存吃緊，關閉其他程序，並且調整jmeter內存，再跑。
2017/04/25 13:59:59 INFO - jmeter.threads.JMeterThread: Thread finished: 線程組 1-484
2017/04/25 13:59:59 ERROR - jmeter.threads.JMeterThread: Test failed! java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at sun.net.www.http.KeepAliveCache$1.run(Unknown Source)
at sun.net.www.http.KeepAliveCache$1.run(Unknown Source)
調整之後再次跑併發測試，
報錯結果爲後端服務端接收http請求後返回異常
系統層面：
tcp連接數超過5000，沒問題
連接中統計連接超時
死套接字超過1000，第一次是2200左右，第二次是1200，說明死套接字回收正常，速度還是可 以的
再看一下。我的系統曾經做過的調優
應用服務器優化：
基本的+
【處理器子系統調優】：開啓超線程，處理器，重要性不言而喻，cpu性能經常是瓶頸，Hyper-Threading（超線程功能，基於SMP 內核），
Hyper-Threading 在操作系統裏將一顆處理器虛擬化爲兩顆使用，使得處理器，同一時刻，可以執行兩個線程或進程
TIME_WAIT相關sysctl參數及超時時間
[root@lvs ~]# sysctl -a | grep tw
net.ipv4.tcp_max_tw_buckets //處於TIME_WAIT狀態的socket數目的最大值
net.ipv4.tcp_tw_recycle = 1 //打開TIME_WAIT快速回收機制
net.ipv4.tcp_tw_reuse //TIME_WAIT狀態socket複用
Sysctl –w net.ipv4.tcp_tw_len = 2 設置TIME_WAIT在2秒後超時
果斷調整tomcat內存情況，（此時系統資源合理）
還是後端壓力過大，死套接字還是佔據tcp資源，返回
Server returned HTTP response code: 502 for URL: http://app.yunce56.cn/v10/message/test/list
來看一下大嬸們關於這波測試給出的建議
假死有兩種情況，1種是time_wait過多，一種是close_wait過多，前者自行優化，後者開發程序問題
我幫你百度了一下，得出一條結論：這個錯誤是由於服務器壓力過大，不能及時處理client的請求導致服務器響應超時而拋出的錯誤
基本上可以得出結論：
即使做過死套接字回收機制+tomcat優化，應用服務器也無法支持瞬間大併發3000，單臺服務器理論65535.停留在涉及理論，（根據業務，有長連接或者是持續連接，做tcp連接回收機制，重點謹慎考慮）
之後採取措施：使用haproxy/lvs + nginx(s)+tomcat(s)。來因對併發，單臺服務器併發3000即有3%左 右連接數無法得到後端及時響應。
返回測試結果。調整架構方案。
架構方案（方案 + 回退機制）
方案
實施：1、停止148nginx，修改配置文件
80->1080
2、啓用haproxy與2臺nginx，tcp觀測端口
啓動，觀察nginx日誌
測試:聯繫開發與測試，boss與wap運行
失敗回退：1、還原/etc/nginx
2、停用haproxy
備註：因阿里雲不支持VIP，故haproxy爲單點，
後期部署ha節點，使用阿里雲負載均衡兩臺ha
效果等同於keepalived+haproxy+nginx+tomcat
注重要的，關於80端口是誰提供的服務，根據架構決定，後來是haproxy+nginx
User:
此最重要，將使用原IP代理80端口，使用haproxy 80端口負載nginx集羣（1080端口），此時haproxy 提供web訪問，將奪取nginx 80端口，域名映射不變。
服務器採購
nginx書寫
haproxy書寫
上一篇文章書寫，關於tomcat優化，借鑑之前的經驗
http://chennailong.blog.51cto.com/10063928/1883671
方案提出，等待夜晚來臨，運維，are you ready ? 2017年4月26日 22:00-凌晨