# StackOverflow 更新：一個月有 5.6 億次網頁瀏覽，25 臺服務器，而這一切都與性能有關 > 原文： [http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html](http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html)  Stack Overflow 的員工對于他們的工作以及原因仍然保持著開放的態度。 因此，該進行另一個[更新](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html)了。 堆棧溢出到底在做什么？ 構成[，StackExchange](http://stackexchange.com/) 的站點網絡（包括 StackOverflow）在全球流量中排名第 54； 它們有 110 個站點，并且以每月 3 或 4 個的速度增長； 400 萬用戶； 4000 萬個答案； 每月有 5.6 億次網頁瀏覽。 這只有 25 臺服務器。 為了一切。 那就是高可用性，負載平衡，緩存，數據庫，搜索和實用程序功能。 全部都有相對少數的員工。 現在就是質量工程。 此更新基于 Marco Cecconi 的 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的體系結構（視頻）和 Nick Craver 的[進行 Stack Overflow](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) 的體系結構。 此外，我還合并了來自各種來源的評論。 毫無疑問，某些細節已經過時了，就像我早在寫這篇文章時所說的那樣，但它仍然具有代表性。 堆棧溢出仍使用 Microsoft 產品。 Microsoft 基礎架構可以正常運行且價格便宜，因此沒有令人信服的理由進行更改。 SO 是務實的。 他們在合理的地方使用 Linux。 沒有純粹的動力來使所有 Linux 或保留所有 Microsoft。 那不會有效。 堆棧溢出仍使用放大策略。 網站上沒有云。 由于其 SQL Server 裝有 384 GB 的 RAM 和 2TB 的 SSD，AWS 會付出巨大的代價。 云還會降低它們的速度，從而更難優化和解決系統問題。 另外，SO 不需要水平擴展策略。 可以在橫向擴展中使用的最大峰值負載沒有問題，因為它們在正確調整系統大小方面非常成功。 因此，杰夫·阿特伍德（Jeff Atwood）的話似乎很：“硬件便宜，程序員昂貴”，這似乎仍然是該公司的絕大部分。 Marco Ceccon 在演講中說，在談論體系結構時，您需要首先回答這個問題：正在解決哪種問題？ 首先是簡單的部分。 StackExchange 做什么？ 它需要主題，在主題周圍創建社區，并創建很棒的問答站點。 第二部分涉及規模。 就像我們將看到的那樣，StackExchange 的增長非常快，可以處理大量流量。 它是如何做到的？ 讓我們來看看...。 ## 統計資料 * StackExchange 網絡有 110 個站點，并且每月以 3 或 4 的速度增長。 * 400 萬用戶 * 800 萬個問題 * 4000 萬答案 * 作為全球排名第 54 的網絡流量站點 * 同比增長 100％ * 每月 5.6 億次網頁瀏覽 * 在大多數工作日，高峰更像是 2600-3000 請求/秒。 編程是一種職業，意味著工作日比周末要忙得多。 * 25 臺服務器 * 2 TB SQL 數據全部存儲在 SSD 上 * 每個 Web 服務器在 RAID 1 中具有 2 個 320GB SSD。 * 每個 ElasticSearch 盒都有 300 GB，也使用 SSD。 * 堆棧溢出的讀寫比率為 40:60。 * 數據庫服務器平均 10％的 CPU 使用率 * 11 個 Web 服務器，使用 IIS * 2 個負載均衡器，其中 1 個處于活動狀態，并使用 HAProxy * 4 個活動數據庫節點，使用 MS SQL * 3 個應用服務器實現標簽引擎，任何通過標簽命中進行搜索 * 3 臺機器使用 ElasticSearch 進行搜索 * 2 臺使用 Redis 進行分布式緩存和消息傳遞的機器 * 2 個網絡（每個 Nexus 5596 +光纖擴展器） * 2 個 Cisco 5525-X ASA（認為防火墻） * 2 個 Cisco 3945 路由器 * 2 個只讀 SQL Server，主要用于 Stack Exchange API * 虛擬機還執行諸如部署，域控制器，監視，用于系統管理員的操作數據庫等功能。 ## 平臺 * 彈性搜索 * 雷迪斯 * HAProxy * MS SQL * [觀察者](https://github.com/opserver/Opserver) * 團隊城市 * [Jil](https://github.com/kevin-montrose/Jil) -基于 Sigil 構建的快速.NET JSON 序列化器 * [Dapper](https://code.google.com/p/dapper-dot-net/) -微型 ORM。 ## UI [ * UI 具有消息收件箱，當您獲得新徽章，收到消息，重大事件等時，將向該消息收件箱發送消息。使用 WebSockets 完成并由 Redis 驅動。 * 搜索框由 ElasticSearch 使用 REST 接口提供動力。 * 由于有如此多的問題，因此不可能僅顯示最新的問題，它們會變化得太快，每秒都會出現一個問題。 開發了一種算法來查看您的行為方式，并向您顯示您最感興趣的問題。它使用了基于標簽的復雜查詢，這就是開發專門的標簽引擎的原因。 * 服務器端模板用于生成頁面。 ## 服務器 * 這 25 臺服務器的工作量不大，即 CPU 負載低。 據估算，SO 只能在 5 臺服務器上運行。 * 數據庫服務器的利用率為 10％，除非在執行備份時服務器突然崩潰。 * 有多低 數據庫服務器具有 384GB 的 RAM，Web 服務器的 CPU 使用率為 10％-15％。 * 放大仍然有效。 其他具有類似瀏覽量的橫向擴展站點通常可以在 100、200，最多 300 臺服務器上運行。 * 系統簡單。 建立在.Net 上。 只有 9 個項目，其他系統有 100 個。 之所以擁有很少的項目，是因為編譯如此迅速，這需要在開始時就進行規劃。 在一臺計算機上，編譯需要 10 秒鐘。 * 110K 行代碼。 給出了它的作用的一小部分。 * 這種簡約的方法存在一些問題。 一個問題是測試不多。 不需要測試，因為那里有一個很棒的社區。 Meta.stackoverflow 是社區的討論站點，并且報告了錯誤。 Meta.stackoverflow 還是新軟件的測試版站點。 如果用戶發現任何問題，他們會報告所發現的錯誤，有時還會報告解決方案/補丁。 * 紐約已使用 Windows 2012，但正在升級到 2012 R2（俄勒岡已經在使用它）。 對于 Linux 系統，它是 Centos 6.4。 * 實際上，負載幾乎遍布 9 臺服務器，因為 10 臺和 11 臺僅用于 meta.stackexchange.com，meta.stackoverflow.com 和開發層。 這些服務器還運行約 10-20％的 CPU，這意味著我們還有很多可用空間。 ## 固態硬盤 * Intel 330 作為默認設置（網絡層等） * 英特爾 520 用于中級寫入，例如 Elastic Search * 用于數據庫層的 Intel 710 & S3700。 S3700 只是高耐用性 710 系列的后繼產品。 * 獨家 RAID 1 或 RAID 10（10 是具有 4 個以上驅動器的任何陣列）。 故障已經不是問題，即使有數百個 intel 2.5 英寸固態硬盤投入生產，也沒有一個故障。每種型號都保留一個或多個備件，但是多個驅動器故障并不是一個問題。 * 鑒于非常頻繁的 SO 寫/重新索引，ElasticSearch 在 SSD 上的性能要好得多。 * SSD [更改搜索](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/#comment-1201059884)的使用。 由于鎖定問題，Lucene.net 無法處理 SO 的并發工作負載，因此將其轉移到 ElasticSearch。 事實證明，在所有 SSD 環境中，實際上都不需要對二進制讀取器進行鎖定。 * 到目前為止，唯一的縱向擴展問題是 SQL 盒上的 SSD 空間，這是由于可靠性與非消費空間中的空間的增長方式所致，即驅動器具有用于功率損耗等的電容器。 ## 高可用性 [ * 主數據中心在紐約，備用數據中心在俄勒岡。 * Redis 具有 2 個從屬，SQL 具有 2 個副本，標記引擎具有 3 個節點，elastic 具有 3 個節點-任何其他服務也具有高可用性（并且都存在于兩個數據中心中）。 * 并非所有數據中心之間都存在從屬關系（不需要通過同步來占用帶寬的非常臨時的高速緩存數據等），而是大數據項，因此在活動數據中心發生故障時，仍然存在共享的高速緩存。 沒有緩存就可以開始，但這不是很優雅。 * Nginx 用于 SSL，但是已經過渡到使用 HAProxy 終止 SSL。 * 發送的 HTTP 總流量僅占發送總流量的 77％。 這是因為正在向俄勒岡州的輔助數據中心以及其他 VPN 通信進行復制。 這些流量的大部分是到俄勒岡州 SQL 復制副本和 Redis 從站的數據復制。 ## 數據庫 * MS SQL Server。 * Stack Exchange 每個站點有一個數據庫，因此 Stack Overflow 獲取一個，超級用戶獲取一個，Server Fault 獲取一個，依此類推。 這些的架構是相同的。 具有不同數據庫的這種方法實際上是分區和水平縮放的一種形式。 * 在主要數據中心（紐約）中，每個集群通常有 1 個主數據庫和 1 個只讀副本。 在 DR 數據中心（俄勒岡州）中還有 1 個只讀副本（異步）。 在俄勒岡州運行時，主要目錄在那里，并且兩個紐約副本均為只讀且異步。 * 有一些皺紋。 有一個“網絡范圍的”數據庫，其中包含登錄憑據和聚合數據（主要通過 stackexchange.com 用戶配置文件或 API 公開）之類的東西。 * 職業生涯 Stack Overflow，stackexchange.com 和 Area 51 都有各自獨特的數據庫架構。 * 所有架構更改將同時應用于所有站點數據庫。 它們需要向后兼容，因此，例如，如果您需要重命名一列-最壞的情況-這是一個多步驟的過程：添加新列，添加適用于兩列的代碼，回填新列，更改 代碼，使其僅適用于新列，請刪除舊列。 * 不需要分區。 索引可以處理所有事情，并且數據還不夠大。 如果需要過濾索引，為什么不提高效率呢？ 僅在 DeletionDate = Null 上建立索引，這是一個常見的模式，其他則是枚舉中特定的 FK 類型。 * 每個項目 1 張表中有投票，例如 1 張表用于投票，1 張表用于評論投票。 我們大多數頁面都是實時呈現的，僅為匿名用戶緩存。 鑒于此，沒有要更新的緩存，只需重新查詢即可。 * 分數是非規范化的，因此經常需要查詢。 所有的 ID 和日期，職位投票表目前只有 56,454,478 行。 由于建立索引，大多數查詢僅需幾毫秒。 * 標記引擎完全是獨立的，這意味著不必依賴外部服務來獲得非常核心的功能。 這是一個巨大的內存結構數組結構，針對 SO 用例和針對重擊組合的預計算結果進行了優化。 這是一個簡單的 Windows 服務，在冗余團隊中的幾個盒子上運行。 CPU 幾乎總是占 2-5％。 負載不需要三個盒子，只是冗余。 如果所有這些操作一次都失敗，則本地 Web 服務器將標記引擎加載到內存中并繼續運行。 * 與傳統的 ORM 相比，Dapper 缺少編譯器來檢查查詢。 編譯器正在檢查您告訴數據庫的內容。 這可以幫助很多事情，但是仍然存在運行時遇到的根本斷開問題。 權衡的一個巨大問題是所生成的 SQL 令人討厭，并且查找其來源的原始代碼通常并非易事。 嘗試優化查詢時，缺乏提示查詢，控制參數化等功能的問題也很大。 例如。 文字替換已添加到 Dapper，以幫助進行查詢參數化，從而允許使用諸如過濾索引之類的內容。 Dapper 還攔截了對 Dapper 的 SQL 調用，并添加了 add 的確切來源。 它節省了很多時間來追蹤事物。 ## 編碼 * 過程： * 大多數程序員都在遠程工作。 程序員在自己的蝙蝠洞中編碼。 * 編譯非常快。 * 然后運行他們已經進行的一些測試。 * 編譯后，代碼將移至開發登臺服務器。 * 新功能通過功能開關隱藏。 * 在與其他站點相同的硬件上運行。 * 然后將其移至 Meta.stackoverflow 進行測試。 每天有 1000 個用戶使用該網站，因此它是一個很好的測試。 * 如果通過，它將在網絡上發布并由更大的社區進行測試。 * 大量使用靜態類和方法，以簡化操作并提高性能。 * 代碼很簡單，因為復雜的位打包在一個庫中，并且是開源和維護的。 .Net 項目的數量保持較低，因為使用了社區共享的代碼部分。 * 開發人員可以獲得兩到三個監視器。 屏幕很重要，它們可以幫助您提高工作效率。 ## 快取 * 緩存所有東西。 * 5 級緩存。 * 第一個：網絡級緩存：在瀏覽器，CDN 和代理中進行緩存。 * 第二名：.Net 框架免費提供的，稱為 HttpRuntime.Cache。 內存中的每個服務器緩存。 * 第三名：Redis。 分布式內存鍵值存儲。 在為同一站點提供服務的不同服務器之間共享緩存元素。 如果 StackOverflow 有 9 臺服務器，則所有服務器都將能夠找到相同的緩存項。 * 第四：SQL Server 緩存。 整個數據庫都緩存在內存中。 整個事情。 * 第五名：SSD。 通常僅在 SQL Server 緩存預熱時命中。 * 例如，每個幫助頁面都被緩存。 訪問頁面的代碼非常簡潔： * 重用了靜態方法和靜態類。 從 OOP 的角度來看，這確實很糟糕，但是對于簡潔的代碼卻非常快速且非常友好。 所有代碼都直接尋址。 * 緩存由 Redis 的庫層和微型 ORM [Dapper](https://code.google.com/p/dapper-dot-net/) 進行處理。 * 為了解決垃圾回收問題，僅創建模板中使用的類的一個副本并將其保存在緩存中。 從統計數據中可以測量所有內容，包括 GC 操作，已知間接層會增加 GC 壓力到明顯的緩慢點。 * 由于查詢字符串哈希值基于文件內容，因此 CDN 命中數有所不同，因此只能在構建中重新獲取它。 300 至 600 GB 的帶寬通常每天點擊 30-50 百萬次。 * CDN 不用于 CPU 或 I / O 負載，而是用于幫助用戶更快地找到答案。 ## 部署 [ * 想要每天部署 5 次。 不要建立宏偉的宏偉的東西，然后再活下來。 重要原因： * 可以直接衡量性能。 * 被迫制造可能起作用的最小的東西。 * 然后，通過 Powershell 腳本構建 TeamCity，然后將其復制到每個 Web 層。 每個服務器的步驟是： * 告訴 HAProxy 通過 POST 使服務器停止旋轉 * 延遲讓 IIS 完成當前請求（約 5 秒） * 停止網站（通過以下所有操作使用相同的 PSSession） * Robocopy 文件 * 啟動網站 * 通過另一個 POST 在 HAProxy 中重新啟用 * 幾乎所有內容都是通過 puppet 或 DSC 進行部署的，因此升級通常僅包括對 RAID 陣列進行核對并從 PXE 引導進行安裝。 它的速度非常快，而且您知道它做得正確/可重復。 ## 團隊合作 * 隊伍： * SRE（系統可靠性工程）：-5 人 * 核心開發人員（Q & A 網站）：?6-7 人 * 核心開發人員：6 人 * 僅針對 SO Careers 產品進行開發的職業團隊：7 人 * Devops 和開發人員團隊確實緊密相連。 * 團隊之間有很多變動。 * 大多數員工都在遠程工作。 * 辦公室主要是銷售部門，丹佛和倫敦則完全是這樣。 * 在所有其他條件相同的情況下，在紐約市更喜歡有一些人，因為面對面的時間對于“完成任務”之間的偶然互動是加分的。 但是，這種設置可以進行實際工作，并且官方團隊合作幾乎可以完全在線進行。 * 他們了解到，親自聘用能夠在任何地方熱愛該產品的最佳人才所帶來的收益遠遠超過其個人收益，而不僅僅是愿意住在您所在城市的人才。 * 某人偏遠的最常見原因是建立家庭。 紐約很棒，但寬敞卻不是。 * 辦公室在曼哈頓，那里有很多人才。 由于數據中心總是在不斷完善，因此它不必離瘋狂的距離。 與 NYC 位置的許多骨干網的連接速度也稍快-盡管我們在這里談論的只是幾毫秒（如果有的話）的差異。 * 組建一支很棒的團隊：愛極客。 例如，早期的 Microsoft 充滿了極客，他們征服了整個世界。 * 從 Stack Overflow 社區雇用。 他們尋求對編碼的熱情，對他人的熱情以及對溝通的熱情。 ## 預算 * 預算幾乎是基于項目的。 僅在為新項目添加基礎結構時才花錢。 利用率如此低的 Web 服務器與 3 年前建造數據中心時購買的 Web 服務器相同。 ## 測驗 * 快速行動并破壞事物。 現場直播。 * 重大更改通過推送進行測試。 開發具有功能相同的 SQL Server，并且它在同一 Web 層上運行，因此性能測試也不錯。 * 很少的測試。 由于 Stack Overflow 的活動社區和大量使用靜態代碼，因此它們不使用許多單元測試。 * 基礎架構發生變化。 共有 2 種，因此只要有可能，就可以使用舊配置進行備份，并具有快速故障回復機制。 例如，keepalived 會在負載均衡器之間快速進行故障回復。 * 冗余系統通常只是為了進行定期維護而進行故障轉移。 通過擁有專用的服務器來不斷測試 SQL 備份，該服務器用于不斷地還原它們（這是免費許可證，可以執行此操作）。 計劃每 2 個月左右啟動一次完整的數據中心故障轉移-輔助數據中心在所有其他時間都是只讀的。 * 每次推送都會運行單元測試，集成測試和 UI 測試。 所有測試必須成功，才能進行生產構建。 因此，關于測試的信息有些混雜。 * 顯然應該進行測試的事物具有測試。 這意味著在 Careers 產品上涉及金錢的大多數事物，以及在 Core 端上易于進行單元測試的功能（具有已知輸入的事物，例如標記，我們的新頂部欄等），而對于大多數其他事情，我們只是做一個功能 手動進行測試并將其推送到我們的孵化站點（以前稱為 meta.stackoverflow，現在稱為 meta.stackexchange）。 ## 監控/記錄 * 現在考慮使用 http://logstash.net/進行日志管理。 當前，專用服務將 syslog UDP 通信插入 SQL 數據庫。 網頁添加了用于出站計時的標頭，這些標頭由 HAProxy 捕獲并包含在 syslog 通信中。 * [Opserver](https://github.com/opserver/Opserver) 和 Realog。 有多少度量標準浮出水面。 Realog 是由 Kyle Brandt 和 Matt Jibson 在 Go 中構建的日志顯示系統 * 通過 syslog 而不是 IIS 從 HAProxy 負載平衡器進行日志記錄。 它比 IIS 日志具有更多的通用性。 ## 陰天 * 硬件比開發人員便宜且代碼高效。 您的速度只有最慢的瓶頸，而且當前所有的云解決方案都具有基本的性能或容量限制。 [ * 如果從第一天開始構建云，您能否構建得那么好？ 最有可能。 您能否一致性地渲染所有頁面，以執行多個最新查詢并跨您無法控制的云網絡緩存獲取數據，并獲得不到 50 毫秒的渲染時間？ 那是另一回事。 除非您談論的是更高的成本（至少 3-4 倍），否則答案是否定的-SO 托管在自己的服務器中仍然更加經濟。 ## 性能為特征 * StackOverflow 非常重視性能。 主頁的目標是在 50 毫秒內加載，但可以低至 28 毫秒。 * 程序員熱衷于減少頁面加載時間并改善用戶體驗。 * 記錄到網絡的每個請求的時間。 借助這些指標，您可以決定改進系統的位置。 * 其服務器以如此低的利用率運行的主要原因是高效的代碼。 Web 服務器的平均 CPU 率為 5-15％，使用的 RAM 為 15.5 GB，網絡流量為 20-40 Mb / s。 SQL 服務器平均約有 5-10％的 CPU，365 GB 的 RAM 和 100-200 Mb / s 的網絡流量。 這具有三個主要優點：一般的增長空間和升級的必要性； 當事情發瘋時（查詢錯誤，代碼錯誤，攻擊等等），可以保持在線的余地； 以及在需要時恢復供電的能力。 ## 經驗教訓 [ * **如果使用 MS 產品，為什么要使用 Redis？** [gabeech](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/cdkpv7w) ：這與 OS 宣傳無關。 我們在運行效果最佳的平臺上運行事物。 期。 C＃在 Windows 計算機上運行最好，我們使用 IIS。 Redis 在我們使用* nix 的* nix 機器上運行得最好。 * **作為策略過度殺傷**。 尼克·克雷弗（Nick Craver）解釋了為什么他們的網絡被過度配置了：20 Gb 大規模殺傷力大嗎？ 您敢打賭，在 20 Gb 管道中，活動的 SQL 服務器平均大約 100-200 Mb。 但是，由于存在大量內存和 SSD 存儲，因此備份，重建等操作可能會使它完全飽和，因此確實可以達到目的。 * **SSD 搖滾**。 數據庫節點均使用 SSD，平均寫入時間為 0 毫秒。 * [了解您的讀/寫工作量](http://sqlblog.com/blogs/louis_davidson/archive/2009/06/20/read-write-ratio-versus-read-write-ratio.aspx)。 * **保持高效運行意味著經常不需要新機器。 只有當由于某種原因需要不同硬件的新項目出現時，才添加新硬件。 通常會添加內存，但是除了該高效代碼和低利用率以外，它不需要替換。 因此，通常談論的是添加 a）SSD 以獲得更多空間，或 b）為新項目添加新硬件。** * **不要害怕專長**。 SO 使用基于標簽的復雜查詢，這就是為什么要開發專門的標簽引擎的原因。 * **僅執行需要做的事情**。 不需要測試，因為活躍的社區已經為它們進行了驗收測試。 僅在需要時添加項目。 僅在必要時添加一行代碼。 您沒有需要它確實有效。 * **重新發明可以**。 通常的建議是不要重新發明輪子，例如，將其變成正方形只會使它變得更糟。 在 SO 上，他們不必擔心制作“方輪”。 如果開發人員可以編寫比已經開發的替代方案更輕巧的東西，那就去做。 * **轉到裸機**。 進入 IL（.Net 的匯編語言）。 一些編碼使用 IL，而不是 C＃。 查看 SQL 查詢計劃。 進行 Web 服務器的內存轉儲，以查看實際情況。 例如，發現拆分呼叫會產生 2GB 的垃圾。 * **沒有官僚機構**。 您的團隊總是需要一些工具。 例如，編輯器，Visual Studio 的最新版本等。只需進行很多操作即可。 * **垃圾收集驅動的編程**。 SO 竭盡全力減少垃圾收集成本，跳過諸如 TDD 之類的做法，避免抽象層，并使用靜態方法。 雖然極端，但結果卻是高性能的代碼。 當您在短窗口中處理數億個對象時，實際上可以測量 GC 運行時應用程序域中的暫停時間。 這些對請求性能有相當不錯的影響。 * **低效代碼的成本可能比您認為的**高。 高效的代碼進一步擴展了硬件，減少了功耗，并使程序員更易于理解代碼。 ## 相關文章 * [關于黑客新聞](https://news.ycombinator.com/item?id=8064534) * [運行堆棧溢出所需的時間[Nick Craver]](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/) * 視頻 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的體系結構，作者 Marco Cecconi * [關于 HackerNews](https://news.ycombinator.com/item?id=7052835) * [演示幻燈片](https://speakerdeck.com/sklivvz/the-architecture-of-stackoverflow-developer-conference-2013) * [Stackoverflow.com：通往 SSL 的道路](http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/) * [哪些工具和技術用于構建 Stack Exchange 網絡？](http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network) * [被 GC 攻擊](http://blog.marcgravell.com/2011/10/assault-by-gc.html) * [StackOverflow 上的 Microsoft SQL Server 2012 AlwaysOn AG](http://www.brentozar.com/archive/2012/09/microsoft-sql-server-alwayson-ags-at-stackoverflow/) * [為什么我們（仍然）相信遠程工作](http://blog.stackoverflow.com/2013/02/why-we-still-believe-in-working-remotely/) * [運行堆棧溢出 SQL 2014 CTP 2](http://nickcraver.com/blog/2013/11/18/running-stack-overflow-sql-2014-ctp-2/) * 多年來，HighScalability 在 StackOverflow 上有幾篇文章：[堆棧溢出體系結構](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html)， [StackOverflow 的擴展野心](http://highscalability.com/blog/2010/2/15/scaling-ambition-at-stackoverflow.html)，[堆棧溢出體系結構更新](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)， [StackExchange 體系結構更新[](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html) 。 這里有 Stack 開發人員-還有一個單獨的 Careers 團隊，專門為 SO Careers 產品進行開發。 也大約有 7 位開發者。 有關首次出現在堆棧上的某些情況，請訪問： [http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow](http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow) “快如閃電”？ 真？ 在稱自己為作家之前，請先了解“閃電”和“閃電”之間的區別 我從來不知道他們在大多數網站上都使用 C＃編寫代碼，考慮到他們僅使用 25 臺服務器，看到這樣的項目進行擴展，真是令人震驚！ （哇） 我對數據庫的低延遲感到驚訝，即使它全部在內存中，也有一些物理瓶頸無法讓您處理超過 20gb / sec 的速度（不確定是什么，取決于內存速度） ）。 很棒的帖子，很驚訝地看到它們繼續運行。 令我的公司感到羞恥的是，我們的服務器從左到右落在中間，僅運行了一部分 SO 運行！ 在 MS SQL 停止讀取 不是.net 人，但是許多項目如何影響編譯時間？ 非常有趣-感謝您的總結！ 很好的簡歷，它很棒的 stackoverflow 原理！ 高性能！ “下降到裸機。進入 IL”。 IL 中的 I 代表中級。 因此，也許應該將其改寫為“更緊密地接近裸機”，但實際上并非如此。 “大多數程序員都在遠程工作。程序員在自己的蝙蝠洞中編寫代碼。” 有點違背 “在其他所有條件相同的情況下，在紐約市更傾向于有人陪伴，因為面對面的時間是在“完成工作”之間進行的隨意互動的加分。但是，這種設置可以進行真正的工作和 官方團隊合作幾乎完全在線上進行。” “他們已經了解到，親自聘用能夠在任何地方鐘情于該產品的最優秀人才而獲得的收益遠遠超過個人受益，而不僅僅是愿意住在您所居住的城市的人才。 ” 出色而翔實，因此令人大開眼界。 對于那些討厭微軟技術棧的人……包括我在內，這是有教益的。 真的很棒。 關于編譯速度和項目數量。 如果在 Visual Studio 中“卸載項目”，則可以禁用該項目的編譯。 我有一個包含 14 個項目的解決方案，而卸載我不從事的項目可以節省大量時間。 >看到這樣的項目可以擴展，考慮到他們僅使用 25 臺服務器，這真是令人震驚 >很棒的帖子，很高興看到他們的運行量 你瘋了嗎？！ 他們在每個數據庫服務器上都有 384GB 的內存。 他們甚至在 Web 服務器上都有 SSD。 他們每個月提供的訪問量僅為 5.6 億，這是整個服務的 560000000 / 30/24/3600 = 216 RPS，如果將其除以 Web 服務器數量，則每個 Web 服務器將為 19 RPS ，而且它不是廉價服務器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 給定像這樣的數字，我會很高興我沒有使用 IIS 或任何 Microsoft 軟件來提供 Web 應用程序... 大量使用靜態類和方法會產生代碼異味 我發現 Marco Cecconi 在 SpeakerDeck 上有一些更新的幻燈片：[](https://speakerdeck.com/sklivvz "https://speakerdeck.com/sklivvz") @Nikita 哦，拜托，你知道數學很愚蠢。 流量顯然遵循模式，幾乎可以肯定，他們在峰值負載下的速度明顯超過 216 RPS。 對于一個相當復雜，寫繁重的網站而言，5.6 億的頁面瀏覽量是非常可觀的。 >停止在 MS SQL 中閱讀 當然可以 > 你瘋了嗎？！ 他們在每個數據庫服務器上都有 384GB 的內存。 他們甚至在 Web 服務器上都有 SSD。 他們每個月提供的訪問量僅為 5.6 億，這是整個服務的 560000000 / 30/24/3600 = 216 RPS，如果將其除以 Web 服務器數量，則每個 Web 服務器將為 19 RPS ，而且它不是廉價服務器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 給定像這樣的數字，我會很高興我沒有使用 IIS 或任何 Microsoft 軟件來提供 Web 應用程序... 您的計算基于以下假設：這是其硬件堆棧可以管理的最大數量。 它在文章中多次聲明，所有內容都超量配置，正常運行負載約為 10％。 您所做的重大損害會導致類似的結論。 如果他們具有關于在最高性能下可以處理多少頁面請求的任何統計信息，那將更加有趣。 即使這樣，它也說明了他們特定的軟件堆棧，將他們認為缺乏 RPS 歸因于 IIS 是愚蠢的 正如 Nikita 所說，這些數字似乎并不令人印象深刻。 我在 SQL 部分中不知道，但是在 HTTP 部分中，只有一臺具有 apache 和 php 的 1GB ram 雙核服務器可以完成這項工作。 Nick Craver-此處的堆棧溢出系統管理員。 我以為我會在這些評論中消除一些混亂和不好的數字。 頁面瀏覽量僅占我們負載的一小部分。 我們為許多 AJAX / JSON 路由和 API 請求提供服務，在任何給定的工作日總計超過 1.3 億個請求。 例如，昨天我們處理了 150,091,472 個請求，平均約為 1730 RPS。 當然，我們有高峰時間與非高峰時間，所以這不是一個很好的指標。 在高峰期，我們通常會在 9 個主要 Web 服務器中的每一個上看到 2600-3000 RPS，負載約為 15％。 供參考：過去 30 天內，我們處理了 3,710,241,322（37 億）個請求。 注意：這些 Web 服務器可能已經使用了 4 年，訂購時并沒有達到最高級的水平（Intel E5640 處理器）。 而且，這些數字不包括每個頁面視圖附帶的我們的 Websocket 連接，它們將使數字甚至更高，并且它們由相同的 9 臺 Web 服務器提供服務。 IIS 和 Microsoft 堆棧并不是所有時間都花在哪里（只有一小部分時間花在這里），它存在于我們的代碼，API 調用，DB 查詢，標簽引擎請求等中。 對我們的網絡的每個請求的*時序細分。 然后，每隔一段時間我們就會通過調整傳遞來發瘋，并取得巨大的性能勝利……這是我們有一段時間沒做過了。 在下一次優化通過之后，我將嘗試發布更新的利用率數字。 同樣值得注意的是，我們提供的幾乎所有內容都不是靜態內容，這些請求由我們的 CDN 處理的時間超過 99.97％。* @bob-托德是一位優秀作家。 但是他可能會考慮雇用編輯。 看來錯別字已得到糾正。 您必須是一個很好的編輯才能趕上這一點。 也許你應該申請這份工作。 有人能解釋為什么“堆棧溢出的讀寫比率為 40:60”嗎？ 如何測量？ 什么構成讀寫操作？ 我對該統計數據感到非常驚訝。 我以為它將具有 99：1 的讀寫比。 與一小部分人發布新問題，答案，投票贊成/反對等等相比，不是大多數人只是查看答案而進行的操作。 很棒的帖子。 作為 stackoverflow 的粉絲，我只是喜歡這個極富啟發性和內容豐富的博客。 很棒的文章，我很奇怪地從工程學的角度看待目前的體系結構。 11 萬行和對抽象的厭惡通常不是成功的工程運動的先兆。 至少在一起時 我希望安裝一些非常有趣的過程來幫助保持平穩運行。 但丁·埃里克（Dante Elrik） 謝謝。 很高興看到有人放棄了他們的基礎架構和方法論。 對于所有批評家：他們所做的都是有效的。 成功了 很穩定 誰在乎這是怎么做的。 他們就是這樣做的，而且顯然很成功。 我敢肯定，如果您想像這些人一樣詳細描述它，那么高可擴展性將發布您的“高級”技術堆棧和公司文化。 就我自己而言，從物理基礎結構到開發人員與“站點可靠性工程師”的比例，我發現這是一本有趣的文章。