3天讓web應用承載拓展1000倍

1、[實戰(zhàn)實戰(zhàn)]3天讓天讓Web應用承載拓展應用承載拓展1000倍2012021614:50|19115次閱讀|來源：williamhertling【已有15條評論】發(fā)表評論關鍵詞：Web應用|作者：夏夢竹編譯|收藏這篇資訊導讀：作者導讀：作者WilliamWilliamHertlingHertling的業(yè)余愛好是寫科幻小說，目前就職于的業(yè)余愛好是寫科幻小說，目前就職于HPHP。他在博客中談到了如何在三天。他在博客中談到了如何在三天內讓一個

2、內讓一個WebWeb應用程序承載拓展應用程序承載拓展1000x1000x的實時并發(fā)訪問量。對此他分享了自己的經(jīng)驗，包括怎么做到、的實時并發(fā)訪問量。對此他分享了自己的經(jīng)驗，包括怎么做到、從中學到了什么，以及從中吸取的經(jīng)驗。從中學到了什么，以及從中吸取的經(jīng)驗。環(huán)境：由環(huán)境：由NgniX，RubyonRails和MySQL構成。注：這個構成。注：這個Web應用只是一個旅行指南。應用只是一個旅行指南。當用戶進入我們的網(wǎng)站時，會通過TripIt導

3、航或者選定目標，再依據(jù)詳細信息進行下面的操作。他們可以根據(jù)自己的喜好選擇不同類別（比如餐廳的菜式風格、評級指標等吸引點進行篩選）?；蛘咭部梢酝ㄟ^瀏覽器查看生活指南做一些預訂。盡管我們的網(wǎng)站還處于beta版中，但是每天仍有幾百萬的訪問量。周一下午2點我們接到一則通知，網(wǎng)站將在周四早上9:30（東部時間）一個非常受歡迎的電視節(jié)目上出現(xiàn)，根據(jù)以往的經(jīng)驗，我們料想這一天將會有20000至150000的需求訪量，峰值可達到10，000，而服務器將

4、承受100x至1000x的需求請求數(shù)。我們估計將會有10000人同時訪問，也就意味著要創(chuàng)建每分鐘約40000頁的請求數(shù)。我們所具備的：我們所具備的：運行于AmazonWebServices，采用EC2云平臺。當CPU負載超過網(wǎng)站服務器端時采用autoscale規(guī)則檢測，EC2實例將增加一倍。部署過程（盡管這成為一種約束）一個月前，花了一周時間將網(wǎng)站性能進行優(yōu)化，將網(wǎng)頁加載時間縮減了30%，大部分是通過減少數(shù)據(jù)庫調用。周一，我們在幾臺電腦

5、上安裝了JMeter（JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具）。你可以使用JMeter編寫腳本從而模擬一個典型的用戶訪問。在以往案例中，會通過腳本來加載首頁，通過選定目標，選擇自己的喜好進入瀏覽，但我們沒有發(fā)表任何留言（如果時間充足的話，我們很樂意去做）。利用模擬用戶將大部分的數(shù)據(jù)庫資料來構建用戶界面。（這一點很重要）。經(jīng)過幾次試驗，我們發(fā)現(xiàn)當線程超過125個時，就無法在單一的JMeter實例上運行了。

6、因此，如果我們要模擬真正的高負荷，這需要將JMeter同時運行在幾臺電腦上。同時，我們還要確定本地網(wǎng)絡不在飽和狀態(tài)，登陸VPN進入另一個網(wǎng)絡，由一個客戶端切換到另一個遠程客戶端。我們很快了解到：我們很快了解到：需要改變最初的autoscale團隊由2臺服務器變成4臺；需要將CPU運行加載由80%降至50%需要將加載持續(xù)的時間由5分鐘減少至1分鐘經(jīng)過這些改變后，讓應用服務端規(guī)模擴大至16臺，但這受到數(shù)據(jù)庫的約束。數(shù)據(jù)庫很快達到100%負荷

7、，盡管我們擴大了AWS（AmazonWebServices）數(shù)據(jù)庫的規(guī)模（超大的CPU和內存）但是仍然受約束。于是我們采用JMeter運行測試，設置平均響應時間為30秒，我們清楚的知道，如果這個問題無法解決，那我們便失敗了。這一天是星期二。我說過“我們會失敗”，此前，我們采取了很多解決措施，團隊中的大部分成員認為這樣做未免太冒險了，會釀成大錯。因為根據(jù)以往100%正確經(jīng)驗：在高負荷加載情況下會導致頁面無法顯示，這是100%有風險的。經(jīng)過

8、幾個小時深思熟慮之后，我們深信，必須要解決可擴展性問題。我們簡要的探討了幾個不同的且動作較大的方法，但這些風險很大：我們簡要的探討了幾個不同的且動作較大的方法，但這些風險很大：復制整個堆棧，并將他們之間的線程改為使用DynDNS或者AmazonsRoute53，因為我們沒有用可以使服務器有5分鐘時間去創(chuàng)建牽引，然后重新運行測試。每秒擴展到120個請求數(shù)（7.200rpm），此時數(shù)據(jù)庫加載時間只有16%。周三下午大約3點鐘，這時數(shù)據(jù)庫服務

9、器可以承受的負荷為每分鐘約36000頁的請求數(shù)。我們再次突破服務器CPU加載的時間。就在這一天，我們已經(jīng)刷爆了EC2實例，我們還有一支團隊一直在忙于擴展性測試，突破了極限。我們去除了AMIs一些不必要的運行，并要求其他人停止測試，我們反復的請求并添加AWS（AmazonWebServices）限制，然后進入客戶代表的賬號，并讓他們提出升級需求。周三晚上很晚我們才離開，此時我們信心倍加，相信能處理好周四早上的超負荷。周四，我們所有人都在使

10、用Google分析NewRelic，它涵蓋了所有屏幕的后端接口，因為它將在PST（太平洋標準時間PacificStardTime）上午5：30開始舉行，我們遍布在酒店的每個角落，用篝火進行實時聊天。第一次加載的時間在5:38分，此時此刻發(fā)生了極大的變化：在短短的一分鐘時間里從原有0訪量變成上千人訪問。頁面響應時間穩(wěn)定在500ms，在服務器客戶端頁面，沒出現(xiàn)過任何延誤。當然，我們也出現(xiàn)Bug，這就要求在加載的時候必須要對此進行修補，然后重

11、新啟動，（可以同時進行），還要確保頁面通暢。加載高峰值我們已測試過，當然，運行的非常好，這也遠遠超過了我們周一下午前所做的改變。因此，這兩天的辛苦，沒白費，我們獲得了回報。經(jīng)驗與教訓：經(jīng)驗與教訓：?如果我們早些使用NewRelicPro計劃，那么我們將節(jié)省很多時間，但是無論用哪種方法，我相信是NewRelic拯救了我們的漏洞，如果我們在周三下午還沒有得到所需要的數(shù)據(jù)，那么周四早上的一切都是扯談。?加載測試需要定期進行，而不是在大事件發(fā)生

12、時才想起測試。在任何時候也許某人使數(shù)據(jù)庫發(fā)生改變，比如忘記了索引或是注入了一些其他的異常性能而又未被發(fā)現(xiàn)，直到系統(tǒng)加載時才知道。?需要一個相對安全的、自動化的方式便于提供執(zhí)行加快部署分段和生產次數(shù)。必需制定捷徑的常規(guī)過程。而不是依賴于某人用vi編輯文件，不會造成任何錯誤。?如果不使用云服務，我們根本不會如此之快擴展應用程序實例和數(shù)據(jù)庫服務器。?團隊的作用很重要，通常情況下，如果不是有危機發(fā)生我們是分散的，各司其職，也不會想到做些遙不可及