--提升性能的同時為你節約10倍以上成本
From: http://blog.sina.com.cn/iyangjian
七，NBA js直播的發展曆程
這一節就談下這個項目發展過程中所遇到的瓶頸，以及如何解決的。
應該是06年吧，當時NBA 比賽比較火,woocall負責高速模式圖文直播放，普通模式和動态比分資料等都放在一群破伺服器上，大概有十幾20台，這些破伺服器有些扛不住了。
因為第二天有一場比較大的比賽，我想埋連接配接線上上測一下效果，于是連夜把财經實時行情server改寫成了NBA JS直播server. 當時有兩台 Intel(R) Xeon(TM) CPU 3.00GHz 雙cpu的伺服器，在F5後面。先啟用一台伺服器，比賽開始前靜悄悄的，不一會，迅速串到了20w connections，再往上增長，就慢的幾乎不可通路， ethtool eth0 , Speed: 100Mb/s, 網卡出口帶寬跑滿了（那時候支援千兆的交換機還不多）。迅速把另一台伺服器啟用，後來又卡了，好象是F5處理能力不足。後來更新伺服器出口帶寬為1G，當然這需要交換機支援千兆口，更換網線，伺服器也從F5後面轉移出來，通過DNS直接輪詢。
後來又測試了幾次，等到新申請的Intel(R) Xeon(R) CPU 5120 @ 1.86GHz，雙核雙cpu伺服器一到，就開始大規模部署，比賽更火了，不巧的是行情也火了起來，我的财經實時圖檔系統和行情系統也是帶寬殺手，同時我也成了伺服器殺手，到處蹭伺服器。IDC帶寬出口開始告急,我每天開始關注哪個機房還有富餘帶寬，有的機房被我們跑的太滿，開始有人勸我們遷移到别的機房。後來 yangguang4勸我支援gzip輸出，我覺得動态壓縮太耗費cpu，不知道預先壓縮是否可行，寫個程式試了一把，沒問題，于是NBA JS直播的的帶寬一下子被砍掉了70%,而且沒浪費一點我們的cpu，賺大了。
之後的兩年裡NBA JS服務一直很穩定，我幾乎都沒怎麼看過，2007年的一場體育賽事中，單機達到25w+ connections，2.86w req/s ,cpu空閑30% ,見下圖 (2CPU*2Core 1.86GHZ伺服器) 。直到奧運期間，有場賽事，woocall瞬間仍給我近200w connections，網通的伺服器被秒殺了1/3。這其實就是善意的DDOS攻擊,這些使用者如果正常進入是沒有問題了，瞬間扔過來，超出了作業系統極限，系統挂掉了，我的服務也over了。在調整核心參數裡有講，怎麼修改核心參數提高伺服器抗秒殺能力，但是不能杜絕。
下圖為2007年一場比賽時,單機25w+ connections，2.86w req/s,的狀态(2CPU*2Core 1.86GHZ):
奧運結束後，我對伺服器程式和架構做了調整，砍掉了2/3的伺服器。但我沒留意的是，同樣connections，實際http請求增加了一倍，因為新上了一個flash方位圖，裡面增加了3個js，增加就增加吧，既然砍了就不準備再恢複了。但是服務在2CPU*4Core centos5 32bit上的表現卻讓我很失望，跑不過2CPU*2Core centos4 32bit 。我開始懷疑程式更新的時候是不是有什麼地方沒考慮到，開始調程式，折騰幾天沒有結果，症狀是單機支撐12.5萬時候沒有任何異常，記憶體使用1%左右，總cpu使用了5%左右，load 0.5，但是再增加0.1w使用者server肯定崩潰，每次都是相同的表現,我知道在什麼地方卡住了。後來看了下dmesg，才恍然大悟，我是被32bit centos 5的核心暗殺的(Out of memory: Killed process xxx)。
32位機上LowFree一般是會變化的(cat /proc/meminfo | grep LowFree)，最大不能超過880M（這個值不能改變除非用hugemem核心)，在centos4 上有核心參數vm.lower_zone_protection(機關是M)來調節LowFree，預設vm.lower_zone_protection=0 ，LowFree=16M，但是在centos5上這個參數貌似被取消了，改變不了。從使用經驗來看，也就是你能申請16M~880M這麼大的連續記憶體，但是16M以上不保證你能申請的到。centos4用到64M以上都沒什麼問題，centos5 用40M+ 就被OOM Killer給斃了。
本周開始使用64bit centos5.2進行測試，遷移很順利，沒有修改一行代碼，他們把整個16G實體記憶體都作為LowFree，這下可以随便揮霍了(盡管如此我還是會節約的)，前幾天的比賽，這個64bit機跑了18w connections，很安靜，未見異常，等有大比賽再檢驗下，沒問題的話就開始大規模使用64bit系統。
目前看來，如果成功遷移64bit系統似乎可以高枕無憂了，但是我還是有兩個憂慮:
1,再突然甩200w connections給我，我不敢保證能扛的住，因為現在伺服器數量消減太多，需要yangguang4那邊做政策調整，在比賽結束後，平滑的把使用者丢給我,這應該有個持續過程，而不是一秒内的瞬間。
2,我猜這個系統，單機支撐到30w conections的時候會遇到瓶頸，因為網卡的中斷集中在cpu0上，沒有均衡開。我們有硬體解決方案已經實作（每個伺服器會多2000RMB開銷）我隻部署了一台，但是軟的還沒實作,寄希望于xiaodong2 。
補充：
昨天的比賽中，一台64bit機，單機支撐30w+ connections，cpu0空閑率隻剩6%，和我的預料是一緻的。當時的CPU總量被我用掉近 1/4，記憶體被我用掉 0.5% 。
下圖為30w+ connections, 4.6w req/s 的時候我的程式使用的資源情況(2cpu*4Core):
下圖為cpu使用分布情況,cpu0空閑率隻剩 6% (2cpu*4Core):
另外附上一個23w connections, 3.5w req/s 的時候我的程式使用的資源情況(2cpu*4Core),當時cpu隻被用掉1/8，記憶體被用掉 0.4% ，cpu沒有發揮線性增加的作用,我肯定不說能我可以支撐23w*8,但是保守地說，隻要把網卡中斷分散一下，單機50w+ connections很easy。
八，新浪财經實時行情系統的曆史遺留問題 (7 byte = 10.68w RMB/year)
這點我還是提下吧，估計我不說，大家也想不到。
先感謝wangyun同學的大膽使用才有了今天的财經實時行情系統（當初是從一台PIII 900伺服器上發展起來的，前幾天剛被我下線）不過 "hq_str_" 這7個位元組的字首，也是他造成的,當初他說改抓取頁面有些麻煩，就讓我寫死在server裡，雖然意識到将來也許會有隐患，但我還是照做了。見下面傳回資料：
http://hq.sinajs.cn/list=s_sz000609,s_sz000723,s_sh000001
var hq_str_s_sz000609="綿世股份,9.29,-0.05,-0.54,170945,16418";
var hq_str_s_sz000723="美錦能源,0.00,0.00,0.00,0,0";
var hq_str_s_sh000001="上證指數,2031.681,-47.436,-2.28,1216967,8777380"; 我算了一筆帳，行情好的時候每秒會産生30~40w個請求，一般一個請求會請求3~50隻股票，保守點就按每個請求5隻股票來計算，每秒會産生200w隻股票查詢資訊。由于這7個位元組産生的帶寬為： 200w * 7byte * 8bit / 1024 /1024 = 106.8 M ,而往往我們的帶寬要按峰值來準備，按1G帶寬100w RMB/year 計算，每年耗費10.68w RMB。把這筆錢拿給我做獎金，我會很happy的 ^-^ . 現在因為很多頁面都使用了行情資料，想修改，代價很高。
是以設計系統的時候一定要考慮的稍微遠一些,哪怕當時隻是一點點微不足道的地方，要考慮将來通路規模變大了會是什麼後果。還有就是要敢于堅持自己的原則。