轉自：https://www.oschina.net/news/96951/framework-benchmarks-round-16

在?TechEmpower Framework Benchmarks 項目?5 周年之際發布了新一輪測試報告:?Round 16.?這一輪對于那些稀飯大數字的人具有相當吸引力. 我們這里說的可不僅僅是每秒吞吐量(有些數字已經大過天了), 還有運行的測試數目(~1830), 測試的框架組合 (~464), 涉及的編程語言?(26), 還有運行一輪所需要的時間 (67 小時, 或者說 2410 億毫秒). 歡迎各位前來圍觀我們的測試報告以及其中漫威式的數字吧.

最近幾個月可謂這個項目最富有激情的階段. 這段時間我們的社區貢獻了許多非常棒的測試實現, 展現了(友善的)性能比拼帶來的趣味. 回頭我們會繼續闡述這點. 這次將是一個稍長一點的 TFB 正式結果宣布, 因為有很多東西我們想和大家一起分享, 所以請耐心讀下去吧.

刀客滿天飛…?刀客飛…?刀客行?

在 15 輪結束之后, 我們大膽挑戰了一個超級任務: 將大約 460 個測試實現從自家釀造的沙箱配置遷移到 Docker 容器中. 這個的確花了我們不少時間, 不過很值得, 整個項目因此受益匪淺.

尤為重要的是因為采用了 Docker, 測試的可重復性和測量的一致性比其以前有明顯提升. 從我們的持續測試結果反饋發現, 每次完整測試之間的變動非常小了.

而我們基本檢測發現因為 Docker 化帶來的性能影響基本上可以忽略不計, 即便有, 也是均勻施加與所有測試上面.

講真, 我們這個項目對 Docker 來說是一個完美匹配, 或者 Docker 對于我們的項目來講是個完美匹配. 唯一的遺憾是當初我怎么沒有碰到你. 還有就是 Docker 的動詞形式是?

刀客滿天飛(Dockerificationization.)

新硬件平臺

三月份的時候我們已經宣布了本輪將在新的硬件平臺上運行, 我們稱之為"Citrine", 擁有 Dell? R440 服務器. 每個都配備了一顆?Xeon Gold 5120?芯, 和一個 10GB 的 cisco 以太網交換機.

因為硬件設備的更換以及 Docker 的引入, 我們沒有生成?R15?和?R16?的變更報告. 因為數據太不相同了,基本上沒有可比性.簡單地說 R16 的成績比 R15 會好很多.

在某些測試中由于吞吐量太龐大了, 我們遇到了"網絡飽和"問題. 還記得?Round 8?嗎? 那次也是同樣的問題, 但當時我們實在 1GB 的網絡上飽和, 這次是 10GB 啊. 我們下次會搞定這個問題的.

(感謝?Server Central?為前幾輪測試提供硬件!)

Plaintext 和 JSON 測試結果的聚集現象

在?Round 16?之前的持續測試中我們已經發現 Plaintext 和 JSON 測試的結果聚集到了 10G 網絡的理論上限. 這意味著一些框架和平臺在允許 HTTP pipelining 的情況下讓我們的 10G 網絡被 140 字節的響應塞滿了, 而我們用的還是一些并不昂貴的商用服務器!

瓶頸現在到了網絡層, 我們正在計劃解決這個問題. 目前的想法是用使用光纖和我們 Cisco 交換機上的 QSFP28 接口對我們的網絡擴容.????

希望能在 Round 17 的時候看到更多關于這個計劃的情況

持續性能測試

在 Round 16 之前我們引入了持續性能測試, 我們的?持續性能測試平臺?在這幾個月愈加完善, 和我們的"刀客行" 一起構建了一個近乎完美的系統, 每隔 67 小時就能讓我們看到新一輪測試結果.

我們想 mark 的幾點:

• 我們并不想搞什么完美的測試結果. 這里的完美是指測試代碼的穩定性和實現細節, 而我們在此并不特意關注這些. 我們的關注點在于參與者是否能持續提高他們框架的性能以及是否能吸引更多的參與者貢獻新的測試. 我們也希望展現今天 Web 開發的多樣性. 關注所謂完美將讓我們偏離我們的既定方向.

• (現在)一次完整的性能測試過程需要 67 小時. 這個時間會隨測試實現的增刪而浮動

• 我們總會增添更多的測試實現, 因此總測試時間會相應延長. 另一方面,我們正在考慮增加單個測試項目的運行時間. 這也將導致總測試時間線性增長

• 我們已經注意到社區在引用持續性能測試結果. 處于我們 (TechEmpower) 自身的需要, 我們還是會繼續定期并發布官方測試報告, 如同本次的 Round 16. 我們也可以利用這個機會寫點博客吸引下眼球不是? 我們希望各位看官繼續關注我們的官方測試報告,踩捧隨意,只要搞得熱鬧就行?

• 總的來說, 持續測試結果是為框架作者和測試代碼貢獻者提供的. 而官方報告則是持續測試結果的低頻度采集, 為所有對 Web 框架性能數據感興趣的人提供指導性數據

關于社交媒體

我們為TechEmpower Framework Benchmarks project 創建了一個 twitter 帳號:?@TFBenchmarks. 別忘了艾特我們.

Round 16 期間我們一直使用社交媒體與社區互動, 并和一些框架的社區合作搞了性能優化活動. Rust 的框架以黑馬的姿態強勢闖入 C, C++, Go, Java 和 C# 的陣營, 成為擁有頂級性能的服務端選手

談到 C#, 這個來自牛氣哄哄的微軟的框架在最近幾輪性能比拼中狂閃黑馬光環. 小子, ASP.NET Core 可不是你老爹時代的 ASP.NET 了.

性能在我心

五年前我們發起這個項目的時候沒有某個特殊目的. 而是一些交織在一起的動機促使了這個項目的誕生: 對蝸速般 Web 應用的無語; 一種希望看到跨平臺性能高端量化數據的渴望; 對性能優化結果預測的證實(或證偽), 或者說揭示性能的奧秘.?而最重要的是我們可能通過此項目來說服人們更多關注性能而讓所有的 web 應用開發者獲益.

一開始我們對項目的期望并不是很高, 而持續不斷的鼓勵讓我們感受到項目正在直接或間接發揮出重要的影響, 我們為此非常振奮.

當被問及這個項目的時候, 我?(Brian)?總是會說平臺和框架是性能的提升最好的地方,這樣能惠及所有使用該平臺或框架的應用開發. 當你的平臺/框架的性能天花板提升之后, 應用開發就獲得額外的空間, 這對他們來講這是一種天賜, 讓他們更加自由的發揮. 與此同時他們可以將性能的擔憂放到后面, 某些情況下甚至永遠也無需慮及性能. 而那些工作在低速平臺的應用開發者則無此幸運, 受限與平臺的性能, 他們常常被迫在應用中引入一些架構級武器, 比如消息隊列, 工作隊列, 集群等, 為應用開發帶來額外的復雜度.

當看到開發者升級到最新的平臺/框架享受到性能提升的時候, 我們也同樣開心.?

我希望此項目所有的參與者能一起分享這種歡樂. 對其他關注軟件速度的朋友也是一樣

Round 17 我們來了!

最后

Round 16 結果:

• Run 6bb9ecf9-5be0-4cb4-b52b-16ea1a3b105b?- 云端結果 - 由 Azure 云提供測試環境.

• Run aad43f39-48a2-460c-a363-99cd543a772a?- 來自我們的?Citrine?服務器結果.

總結

以上是生活随笔為你收集整理的(转)Web Framework 的速度与激情 16 正式上映的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。