# MySpace 如何與 100 萬個并發用戶一起測試其實時站點 > 原文： [http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html](http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html) 這是 [SOASTA](http://www.soasta.com/) 副總裁 Dan Bartow 的嘉賓帖子，內容是他們如何使用 800 個 EC2 實例與 100 萬并發用戶共享 MySpace。 我認為這是一個有趣的故事，因為：用戶很多，需要花費大量的精力來測試您的實時站點，而并非所有工作都能按預期進行。 我要感謝 Dan 抽出寶貴的時間寫和分享這篇文章。  在 MySpace 音樂先前取得成功的基礎上，MySpace 在 2009 年 12 月在新西蘭掀起了新的流音樂視頻產品浪潮。 這些新功能包括觀看音樂視頻，搜索藝術家的視頻，創建收藏夾列表等等的功能。 在 MySpace 等熱門網站上，此類功能的預期負載增加是巨大的，他們希望在啟用這些功能之前先進行測試。 如果您管理高流量應用程序背后的基礎架構，則不會感到意外。 您想了解自己的斷裂點，定義容量閾值，并知道在超過這些閾值時如何應對。 用實際的預期負載水平測試生產基礎架構是了解高峰流量到達時事物將如何運行的唯一方法。 對于 MySpace，目標是在其實時站點上測試另外的 100 萬并發用戶，以強調新的視頻功能。 這里的關鍵詞是“并發”。 不到一個小時或一天的時間……網站上同時有 100 萬用戶同時活動。 應當指出，一百萬個虛擬用戶只是 MySpace 在高峰期通常在站點上擁有的虛擬用戶的一部分。 他們想用測試流量來補充實時流量，以了解新產品對整個基礎架構的總體性能影響。 這需要大量的負載生成功能，而這正是云計算發揮作用的地方。 為了進行此測試，MySpace 與 SOASTA 一起使用了云作為負載生成平臺。 以下是測試過程中生成的負載的詳細信息。 所有數字均與虛擬用戶的測試流量有關，不包括實時用戶的指標： * 100 萬個并發虛擬用戶 * 測試用例分為搜索和觀看音樂視頻，對視頻進行評級，將視頻添加到收藏夾以及查看藝術家的頻道頁面。 * 每秒 16 吉比特的傳輸速率 * 每小時傳輸 6 TB 的數據 * 每秒點擊次數超過 77,000，不包括實時流量 * 800 個用于生成負載的 Amazon EC2 大型實例（3200 個云計算核心） **測試環境體系結構** SOASTA CloudTest?管理對云提供商（在本例中為 Amazon）的調出，并配置服務器以進行測試。 捕獲 800 個 EC2 實例的過程用了不到 20 分鐘的時間。 我們對 Amazon EC2 API 進行了調用，并以 25 個為一組請求服務器。在這種情況下，團隊正在請求具有以下規范的 EC2 Large 實例充當負載生成器和結果收集器： * 7.5 GB 內存 * 4 個 EC2 計算單元（2 個虛擬 CPU 內核，每個虛擬 CPU 內核具有 2 個 EC2 計算單元） * 850 GB 實例存儲（2×420 GB 加上 10 GB 根分區） * 64 位平臺 * Fedora Core 8 * 另外，有 2 個 EC2 Extra-Large 實例充當測試控制器實例和結果數據庫，其規格如下： * 15 GB 內存 * 8 個 EC2 計算單元（4 個虛擬內核，每個虛擬內核具有 2 個 EC2 計算單元） * 1,690 GB 實例存儲（4×420 GB 加上 10 GB 根分區） * 64 位平臺 * Fedora Core 8 * PostgreSQL 數據庫 一旦擁有測試所需的所有服務器，便開始對它們進行運行狀況檢查，以確保它們響應并穩定。 當發現死服務器時，它將丟棄它們，并請求其他服務器來填補空白。 設置基礎結構相對容易。 下圖（圖 1）顯示了如何在 EC2 上設置測試云以將大量負載推入 MySpace 的數據中心。  **圖 1\.** 測試運行時，成批的負載生成器將其性能測試指標報告回單個分析服務。 每個分析服務都連接 到 PostgreSQL 數據庫，以將性能數據存儲在聚合存儲庫中。 這是這種規模的測試可以擴展以生成和存儲大量數據的方式的一部分-通過將對數據庫的訪問限制為僅度量指標聚合器并水平擴展。 **挑戰** 由于規模往往會破壞一切，因此在整個測試過程中會遇到許多挑戰。 **該測試僅限于使用 800 個 EC2 實例** SOASTA 是云計算資源的最大消費者之一，通常在多個云提供商之間一次使用數百臺服務器來進行這些大規模負載測試。 在測試時，團隊要求提供的 EC2 實例數量上限。 可用硬件的限制意味著每個服務器都需要模擬相對大量的用戶。 每個負載生成器模擬了 1,300 至 1,500 個用戶。 此負載水平約為典型 CloudTest?負載生成器將驅動的負載的 3 倍，這給產品帶來了新的壓力，工程團隊需要一些創造性的工作來解決。 用于減輕負載生成器壓力的一些策略包括： * 錯開了每個虛擬用戶的請求，以免每個負載生成器的點擊都一次觸發 * 縮減收集的數據，僅包括性能分析所需的內容 ## **MySpace 資產的很大一部分由 Akamai 提供，并且該測試反復使 Akamai 基礎架構** 的部分服務能力最大化。 CDN 通常會根據訪問者的地理位置從最接近訪問者的位置向他們提供內容。 例如，如果您從亞馬遜的東海岸可用區生成所有測試流量，那么您很可能只會遇到一個 Akamai 服務點。 在負載下，該測試正在向少量 Akamai 數據中心生成大量數據傳輸和連接流量。 這意味著這些數據中心的負載將超過典型高峰期間可能產生的負載，但是鑒于此功能啟動僅針對新西蘭流量，因此這不一定是不現實的。 這種壓力導致新連接在某些負載水平下被 Akamai 破壞或拒絕，并在測試中產生許多錯誤。 這是在生產現場產生負載時需要克服的常見障礙。 需要設計大規模生產測試，以考慮到這一點并準確地對整個生產生態系統施加壓力。 這意味著從多個地理位置生成負載，以便將流量分散到多個數據中心。 最終，了解地理 POPs 的能力是該測試的重要收獲。 ## **由于額外負載的影響，MySpace 必須即時調整其某些服務器的位置，以支持正在測試的功能** 在測試過程中，額外的虛擬用戶流量使 MySpace 基礎架構中的一些負擔沉重。 MySpace 的運營團隊能夠在幾分鐘內從其他功能集群中獲取未充分利用的服務器，并使用它們為視頻站點集群增加容量。 也許最令人驚奇的是 MySpace 能夠做到這一點。 他們能夠實時監控整個基礎架構的容量，并在需要時靈活地收縮和擴展。 人們一直在談論彈性可伸縮性，這在實踐中是一件很美的事情。 **經驗教訓** 1. 對于高流量網站，在生產中進行測試是準確了解容量和性能的唯一方法。 對于大型應用程序基礎結構，如果您僅在實驗室中進行測試然后嘗試進行推斷，那么就會出現太多“看不見的墻”。 2. 彈性可伸縮性正成為應用程序體系結構中越來越重要的部分。 應該構建應用程序，以便可以獨立監視和擴展關鍵業務流程。 能夠相對快速地增加容量將成為來年的關鍵體系結構主題，而大型企業早就知道了這一點。 Facebook，Ebay，Intuit 和許多其他大型網站都宣揚了這種設計原則。 使事物保持松散耦合具有以前宣傳過的許多好處，但是容量和性能正在迅速移到該列表的前面。 3. 實時監控至關重要。 為了對容量或性能問題做出反應，您需要進行實時監控。 此監視應與您的關鍵業務流程和功能區域相關聯，并且需要盡可能實時。 ## 相關文章 * [MySpace 體系結構](/blog/2009/2/12/myspace-architecture.html) * [如何在不進行實際嘗試的情況下成功完成容量規劃：Flickr 的 John Allspaw 專訪他的新書](/blog/2009/6/29/how-to-succeed-at-capacity-planning-without-really-trying-an.html) 另一篇令人失望的簡短文章：/ 這篇文章對于學習和觀察真實的云一樣有用。 這本來真是令人贊嘆的文章，但事實證明，更多的是 soasta 廣告：( 嗯 我也希望有更多細節。 里面沒有什么新東西，只是一則廣告。 您想要保羅什么細節？ 我想知道這項測試的亞馬遜賬單是多少？ 雖然可能有點像廣告，但我不認為這太過分了。 SOASTA 僅被特別提及了三遍，考慮到它們都執行了測試并撰寫了有關測試的文章，這似乎是合理的。 總體而言，我認為這是一篇相當不錯的文章，并為我提供了許多以前所沒有的見識。 也許是因為我沒有參與需要進行云部署測試的大型站點。 如果是的話，我可能會有所不同。 根據讀者的不同，一篇文章幾乎總是細節太少或太多，我認為這篇文章取得了很好的平衡。 感謝您的撰寫。 這聽起來像是廣告，它實際上是一項糟糕的服務。 強調 Akamai 在美國的基礎設施將如何幫助應對來自新西蘭的流量猛增？ 這些新西蘭人最終將身處 Akamai 的新西蘭基礎設施中。 另外，如果要在 MySpace 上對后端進行負載測試，而不是 Akamai 提供內容，則根本不需要測試 Akamai 部分。 只需在 MySpace 網絡中內部運行測試即可。 最后，哪種產品需要 16 GB 的 RAM 才能同時下載一些 http 請求？ 你在開玩笑吧。 Java 用什么寫的？ 這篇文章讓人印象深刻。 鑒于單核奔騰 M 筆記本電腦可以輕松使千兆位以太網連接（尤其是傳入）飽和，因此沒有理由使用 16 臺以上的服務器。 從亞馬遜那里購買它們特別愚蠢，因為與新西蘭的 DSL 客戶相比，它們往往連接良好。 如果啟動該服務確實產生了如此大的影響，那么您將受到新西蘭微薄的互聯網連接的自然限制，并且必須與所有其他新西蘭人共享。 關于先前的投訴，我認為您至少讓讀者停滯了一點： （1）對于僅命中一個 Akamai 數據中心的問題有什么解決方案？ 您是否能夠克服該瓶頸并測試其他潛在瓶頸？ 我也想知道： （2）是否遇到任何挑戰 -傳輸速率為每秒 16 吉比特 -每小時傳輸 6 TB 數據 進入 Amazon AWS？ 還是僅僅是產生足夠多的實例來獲得這種傳輸速率？ 您能否說明一下為什么選擇 PostgreSQL 來存儲日志數據？ 我很確定某些鍵值存儲系統會比常規 SQL 系統更快地占用資源，同時存儲日志數據。 盡管它沒有描述所有細節，但了解/聽到使用 EC2 進行這種負載測試的方法仍然非常有趣。 謝謝 費利克斯（Felix），即使您的行為像孩子一樣在 YouTube 上匿名發動，我還是決定，我會盡力為您解答問題。 他們來了： >強調 Akamai 在美國的基礎設施將如何幫助應對來自新西蘭的流量猛增？ 這些新西蘭人最終將身處 Akamai 的新西蘭基礎設施中。 來自 Akamai 的內容只是正在測試的整個基礎架構的一部分。 這是在測試設計期間提出的，并被團隊接受，因為： 1）沒有其他選擇-尚無主要的云播放器在新西蘭（但是）擁有與某些較大的播放器一樣強大的 API，并且具有一定數量的服務器 2）大多數 Akamai 的存在都相對 在性能方面具有可重復性，因此，由于我們主要測試的不是 Akamai，因此我們假定來自新西蘭其他數據中心的性能也與眾不同，因為每個人都愿意接受這種風險。 有了 SLA，并且對數據中心進行的壓力測試比預期的要高得多，這在邏輯上是可以接受的風險。 > >如果要在 MySpace 上對后端進行負載測試，而不是 Akamai 提供的內容，則根本不需要測試 Akamai 部分。 只需在 MySpace 網絡中內部運行測試即可。 如果您希望基礎架構的所有部分都能承受預計的負載的 100％的信心，則每個組件都需要進行測試。 我們經常根據客戶的要求測試 CDN。 在這種情況下，沒有人想到 CDN 會遇到麻煩，但我們遇到了很多麻煩。 即使我們可能一直在強調一種持久性有機污染物，其強度比預期的要高，但我們觀察到一個以前沒有人知道的能力點。 要記住的一件事是，它不僅僅是從容量角度測試 Akamai。 當本應由 Akamai 提供服務但沒有提供服務時，會發生不好的事情，最終回到原始服務器并破壞 MySpace 基礎結構。 團隊需要首先確保內容全部來自 Akamai。 其次，我們需要確保在 Akamai 緩存刷新等過程中沒有負載傳遞到 MySpace。 同樣，在內部運行測試不能像在防火墻外部進行測試那樣準確地提供性能信息。 > >哪種產品需要 16 gigs RAM 才能同時下載一些 http 請求？ 你在開玩笑吧。 Java 用什么寫的？ 不值得花時間回答這個問題。 如果聽起來讀者理解這里發生的一切，就很樂意做出回應；） > >本文頗為令人印象深刻。 鑒于單核奔騰 M 筆記本電腦可以輕松使千兆位以太網連接（尤其是傳入）飽和，因此沒有理由使用 16 臺以上的服務器。 從亞馬遜那里購買它們特別愚蠢，因為與新西蘭的 DSL 客戶相比，它們往往連接良好。 如果啟動該服務確實產生了如此大的影響，那么您將受到新西蘭微薄的互聯網連接的自然限制，并且必須與所有其他新西蘭人共享。 在線應用程序的性能測試遠不止于飽和。 在下載或流式傳輸內容時，實際上保持打開狀態的打開線程和套接字是您逐個服務器消耗所有容量的地方。 下載內容需要時間，并且在下載或流式傳輸內容時，您失去了生成負載的能力。 除此之外，對于性能測試，您還不會發出請求以生成負載并將其釋放。 您正在記錄有關每個用戶的大量性能數據。 每次命中所花費的時間，傳輸的帶寬，錯誤以及類似性質的事情。 在 DSL 點上，帶寬限制很少在性能測試中完成，因為如果最終用戶連接不受應用程序公司的控制，則不會進行限制。 > >（1）僅命中一個 Akamai 數據中心的問題的解決方案是什么？ 您是否能夠克服該瓶頸并測試其他潛在瓶頸？ > 我們接受了這樣的風險，即我們實際上要測試一個 Akamai 的存在點，其強度要高于此次發布的程度。 但是，識別瓶頸是一項關鍵的學習，并且隨著流量的增長，運營團隊和他們的頭腦現在已經知道了解其閾值，這可能是需要逐步解決的問題。 >我也想知道： > >（2）在獲得 > >方面是否存在任何挑戰-每 16 吉比特的傳輸速率 第二 >-每小時傳輸 6 TB 的數據 > >到 Amazon AWS？ 還是僅僅是產生足夠多的實例來獲得這種傳輸速率？ > 我很想告訴您是否有，但完全沒有挑戰。 只是產生 EC2 實例就給我們帶來了其他一切，包括看似開放的數據傳輸管道和磁盤訪問，以及 I / O 都可以正常工作。 實際上，在與亞馬遜合作進行了 3 年這些測試之后，我們從未遇到任何帶寬或 I / O 問題。 我喜歡這篇文章，感謝您撰寫。 托德（Todd）-如果您要花時間反駁某項陳述，最好花點時間進行拼寫檢查以提高信譽 除了 MySpace 本身之外，其他各方（Akamai 和/或沿途的其他運營商）是否也了解這種“受控 DoS”？ 是否不增加容量來處理流量的突然增加，但至少要知道這是請求的合法流量，而不是某些 DoS 攻擊？ 您可以從 Amazon 獲得如此多的實例和資源，這沒有問題，因為 Amazon 知道您是誰以及這是一家什么樣的公司，因此他們消除了對您帳戶的任何限制？ 還是亞馬遜真的有這么多的產能供任何支付者使用？ 該測試花了多長時間？ 您準備了多長時間了？ 您是否想念一些后來才意識到有用的數據？ 您是在看到 MySpace 正在處理負載還是在從頭到尾從 0 到 1 磨時增加點擊量嗎？ 對于我的一項工作，我們進行了類似的測試； 一切順利，直到我們開始生產為止。 即將發布的消息是，我們的某些后端日志記錄和報告系統正在執行 DNS 反向查找。 由于我們的測試來自有限的 IP 空間，因此查找并不是全部可見-但是由于數千名用戶使用不同的 IP 位置，我們發現這造成了巨大的瓶頸。 值得牢記。 哇，我無法想象必須處理所有的流量以及在“開放”期間可能出現的任何問題。 我已經處理了高流量的網站，但沒有像 Myspace 這樣的網站。 我從事表演業務，并使用云模擬了 40,000 個虛擬用戶。 這篇文章強調了我面臨的一些問題-大型數據集，將負載分散到可用區域等。還有一個我還沒有解決的問題，那就是 jmeter 無法像瀏覽器一樣進行并行下載。 當下載頁面命中的所有資源時，這反映在較大的事務響應時間中。 在澳大利亞和美國西部之間的每次請求中，RTT 為 250 毫秒也會使情況變得更糟。 到目前為止，我不得不在報告中說明這一點，盡管結果表明事務 x 花費了 12 到 15 秒之間的時間，但這實際上相當于 0.5 到 3.5 秒的響應時間，并且總吞吐量并不是瓶頸。 SOASTA 加載工具是否可以執行并行下載，您是否考慮了 250 毫秒的 RTT？ 另一件事-如果同時有 100 萬新西蘭人同時使用 Myspace，那么那里的街道將空無一人。 哦，還有一件事。 當然，您可以從一臺筆記本電腦運行 1,000 個用戶。 您不會達到 1GB /秒的速度。 您的響應時間度量將反映測試硬件（而不是被測系統）中的延遲。 關鍵在于您的負載生成器是否可以及時處理網卡生成的中斷。 SeaPerf，為什么您不閱讀他的講話而不是尋找拼寫錯誤？ 獲得生活。 沒有人需要互聯網上的另一位抱怨拼寫的笨蛋。 你好 感謝您的文章，這很有趣。 我正在研究這個主題，并且有一些問題。 也許你可以幫忙。 您如何定義我們需要強調的計算機數量。 例如，如果我在瓶頸所在的位置使用 apache bench，那么我可以同時運行 1000 個用戶嗎？ 網絡，CPU 和 RAM 有一些瓶頸，如何定義它們？ 對于較小的壓力測試，您建議使用哪種軟件？ （Apache Bench，JMeter，Siege 等），以及如何定義場景？ （使用 Jmeter 代理，處理 apache 訪問日志嗎？） 西里爾