本篇文章是個經驗談，作者想要聊聊是如何將一個 4vCPU 的VM給調整到可以達到每秒處理 1.2M(120萬)個 JSON Reuqest，本篇文章非常的長，所以會分多天來介紹。

整篇文章探討的是各種 turning 的步驟，來聊聊如何從最初每秒 224k(22萬四千) 給調整到每秒 1.2M 的處理能力。

整個過程分成九大步驟，後面同時標示每個過程後的每秒請求能力
1. Application Optimizations (347k)
2. Speculative Execution Migtigations (446k)
3. Syscall Auditing/Blocking (495k)
4. Disabling iptables/netfilter (603k)
5. Perfect Locality (834k)
6. Interrypt Optimizations (1.06M)
7. The Case of the Nosy Neighbor (1.12M)
8. The Battle Against the Spin Lock (1.15M)
9. This Gost to Twelv (1.20M)

作者強調，上述的過程不一定適合你的應用程式，但是透過這些步驟能夠讓你更佳瞭解應用程式的運作行為，同時也有機會發現一些潛在的瓶頸問題。

環境介紹
1. 團隊使用 Techempower 來進行 JSON Serialization 的測試
2. 使用 libreactor(event-driven框架) 來搭建一個簡單的 API Server
3. HTTP 的解析使用 picohttpparser，同時使用 libclo 來處理 JSON 的編碼
4. 硬體環境
- Server: 4 vCPU, c5n.xlarge AWS VM
- Client: 16 vCPU, c5n.4xlarge AWS VM (clinet太弱會變成瓶頸)
- Network: Server/Client 屬於同一個可用區域(AZ)
5. 軟體環境
- 作業系統: Amazon Linux2 (Kernel 4.14)
- Server: 使用 libreactor (使用不同版本，分別是 Round18 以及 Round20)
- Client: 修改 wrk 這個知名的工具並重新命名為 twrk，詳細差異自己看文章內部，主要都跟顯示有關
6. 實驗方式
- 每個測試跑三次，取中間值
- 256 連線，16 threads，同時每個 thread 都會 pin 到一個固定的 CPU
- 每個實驗都有兩秒的暖機時間來建立連線


Ground Zero
第一個要探討的就是什麼最佳化都還沒有使用前，到底當前應用程式可能的瓶頸在哪裏
首先團隊將該應用程式與其他常見的應用程式或是開發框架比較，譬如 Netty, Nginx, Actix, aspcore 等， libreactor 的效能不錯，有中上水準。

接者作者使用火焰圖(Flame Graphs)來 Profile 該伺服器，作者很好心地將文章中所有的火焰圖都調整了一下，讓所有的 user-space 相關的 function call 都轉成藍色，而剩下跟 kernel 相關都維持紅色。
1. 大部分的時間都在 Kernel 處理
2. 主要是花費在收封包與送封包
3. 應用程式本身主要是分兩大部分，解析 HTTP 的封包以及處理請求與回應。
從上述兩點來看，作者認為目前的應用程式寫得算不錯，因為瓶頸很明顯是卡在 Kernel 端

接下來就正式進入到各種 Turning 的章節探討

Application Optimizations

長話短說:
- 作者基於 libreactor Round18 的框架進行修改，並且所有的修改都已經被合併到 Round20 的版本中，而這些修改主要是實作方面的強化以及整個框架的最佳化。

1. 作者首先透過 htop 觀察運行過程，發現 Server 只有使用 2vCPU 而已(系統有 4vCPU)，因此這是作者進行的第一個修改，讓 Server 使用了 4vCPU，這個簡單調整就讓效能提升 25%

註: 作者特別強調，不要覺得從 2vCPU 變成 4vCPU 效能就可以變成兩倍，主要是1) 沒有使用的 vCPU 還有很多其他的工作要處理，因此不是完全都送給你應用程式處理。2)基於 hypter-thread vCPU 的架構，環境只有兩個真正的 CPU 而是透過邏輯的方式產生四個抽象的 CPU，所以全用一定會變快，但是基於很多資源還是要競爭與共用，數字不是單純翻倍

2. 作者自己的應用程式本身使用 gcc 建置時有使用 "-o3" 的方式來最佳化處理，然而框架本身卻沒有使用 "-o3" 的方式來弄，因此作者也針對這個部分來處理，讓建制框架時能夠使用 -o3
3. 從實作方面來看，作者觀察到 libreactor 1.0 版本使用的是 read/write 這兩個常見的方式來處理封包的送收，作者將其修改成 recv/send 整個效能就提升了將近 10%。

註: write(針對 FD，更全面廣泛的用法) 與 send(針對 Socket，更針對的用法) 使用上差異不大，但是 write 於底層 Kernel 最終還是會呼叫到 send 來處理，所以基本上可以理解就是在沒有特別參數需求時，可以直接跳過幾個 kernel function 來達到加速的效果。

write kernel 內的走向: sys_write -> vfs_write -> __vfs_write -> sock_write_iter -> sock_sendmsg

send kernel 內的走向: sendto -> sock_sendmsg

4. 作者觀察到火焰圖中有一些 pthread 相關的資料，進而發現 libreactor 會創造一個 thread pool 來處理非同步的 DNS 名稱解析問題。對於一個 HTTP Client 來說，如果今天要發送請求到多個不同的 domain，而每個 domain 都會需要進行一個 blocking 的解析過程，透過這種方式可以減少 DNS 解析造成的 blocking 問題。然而對於 HTTP Server 來說，這個使用情境帶來的效益似乎就稍微低了些，畢竟 Server 只有 Bind Socket 之前可能會需要去解析一次 DNS 而已。
大部分的情境下， thread pool 都是應用程式初期會去創造而接者就不太會管她，但是對於錙銖必較的效能除錯人來說，任何能夠調整的部分都可能是個值得探討的地方。
作者透過修改 Server 端(準確來說是 libreactor 框架內的程式碼)關於 Thread Pool 的一些用法，成長的讓整個效能提升了 2~3%

結論來說，透過上述四個概念來提升的程式碼效能。
1. vCPU 盡量使用: 25%-27%
2. 使用 gcc -O3 來建置框架的程式碼: 5%-10%
3. 使用 march=native 等參數來建置最後的 server 應用程式: 5%-10%
4. 使用 send/recv 而非 write/read: 5%-10%
5. 修改 pthread 的用法: 2%-3%

註: 作者強調每個最佳化的結果並非是單純累積的概念，反而還會有互補的效果。
可能前述的操作實際上也會讓後續的操作達到更好的效果，
譬如如果先跑 vCPU 的調整，效能大概提升 25%，但是如果先執行別的最佳化過程，最後再來調整 vCPU，就可以達到 40% 的效果，主要是 CPU 可以共有效率的去執行程式。

最後，這個部分讓整個處理封包能力從 224k 提升了 55% 到 347k (req/s)。
從火焰圖來看，整個 user-space 的範圍縮小許多，同時 send/recv 的處理也有使得整體的高度下降一點點(大概四格..)

為了避免文章過長，本篇文章就探討第一個最佳化的過程，剩下的就敬請期待後續!

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

新品快訊: ADI發表通過UL 217測試及驗證的煙霧探測器參考設計和演算法

Analog Devices, Inc. (ADI)推出有助於快速實現精小尺寸、低功耗煙霧探測器原型設計的參考設計和演算法，使煙霧探測器能以更低的成本更快推向市場。新發表的CN0537可降低設計風險，並已經通過測試和驗證，符合UL 217煙霧報警器標準（第8版）。該參考設計採用ADI的ADPD188BI高性能光學感測器核心，並配合使用精密煙霧腔以減少誤報。

• 如需下載電路筆記，購買演算法、UL-217認證的數據集，以及原始程式碼和參考平台硬體，請瀏覽：www.analog.com/CN0537

• 觀看CN0537影片: https://www.analog.com/en/education/education-library/videos/6195684962001.html

• 瞭解有關ADI 煙霧探測解決方案的更多資訊

• 透過線上技術支援社群EngineerZone™聯繫工程師和ADI產品專家：ez.analog.com

CN0537參考設計的主要特點:
• 通過UL 217（第8版）測試和驗證的煙霧與火災探測演算法
• 用於演算法開發的數據封包，包含通過UL-217認證設備獲取的超過1,000個煙霧數據集
• 提供數據預處理、初始化、校準和環境補償原始程式碼的軟體
• 採用Arduino外形尺寸的煙霧探測器參考設計，用於快速原型設計和開發
• 低功耗硬體設計和計算複雜度較低的演算法，可延長電池壽命，縮減電池尺寸和成本

5G趨勢月報第8期：

文/余至浩 | 2020-06-29發表

宜蘭縣展示5G智慧農業IoT應用雛型，更要靠傳輸4K影像讓蟲害辨識預警更早一步

目前這套智慧農業IoT監控系統主要是安裝在宜蘭壯圍鄉一處溫室農園裡，做為當地智慧化種植哈密瓜的示範場域，裡面除了4G，還可支援下一代高速5G傳輸網路。

該套IoT監控系統還升級為支援5G傳輸架構，只要有電信營運商在當地開通5G服務，就可以馬上使用，來加快數據分析，未來還可運用它傳輸4K畫質影像，進行蟲害影像辨識模型的訓練，讓以後蟲害辨識預警能更快速且精準。

宜蘭縣展示智慧農業IoT應用成果，可支援高速5G傳輸加快數據分析提升哈密瓜種植品質

宜蘭縣府近日公開展示智慧農業應用成果，透過其農業IoT種植生產系統，來蒐集溫溼度、雨量、日照等數據，提升哈密瓜種植品質，而且除了4G，還可支援下一代高速5G傳輸網路。目前這套IoT監控系統主要是安裝在宜蘭壯圍鄉一處溫室農園裡，做為當地智慧化種植哈密瓜的示範場域，裡面使用天龍安全科技提供的TIAGA智慧神農AI系統，來對哈密瓜種植生長環境進行數據蒐集與監測，至今已可做到8成高品質的果品產出。該團隊更與仁寶電腦合作，將這套IoT系統升級為支援5G傳輸架構，只要有電信營運商在當地開通5G服務，就可以馬上使用，來加快數據分析，未來還可運用它傳輸4K畫質影像，進行蟲害影像辨識模型的訓練，讓以後蟲害辨識預警能更快速且精準。

5G應用 中華電信

中華電信展示結合5G的智慧公車應用，搶先開放民眾免費搭乘

為了展現5G技術帶來的嶄新應用，中華電信趕在5G開臺之際，與臺北市聯手推出5G體驗公車服務，讓民眾能搶先體驗。這項體驗服務結合了臺北市政府提供的實驗場域，並由中華電信在信義區架設5G基地臺，利用公車上的5GCPE裝置接收5G訊號，展示在公車行駛之下，仍能透過5G網路順暢串流播放8K/4K超高畫質影片。戶外實測時，5G連網速度可達800Mbps左右，而在一般室內空間速度更快有到1.49Gbps。這輛公車也搭載360度監控系統，可讓駕駛監控公車行駛時的四周車側影像，而透過5G即時傳輸影像，可從遠端監控公車駕駛是否有進食、打瞌睡等分心的危險駕駛行為。或是也能取得路邊號誌的交通資訊，提升行車安全。5G體驗公車已從6月11日起，為期三周在臺北市信義區繞行，並開放民眾體驗。無獨有偶，在早之前，臺北市政府另一輛自駕巴士，也使用遠傳的5G網路來進行車聯網應用相關測試。

臺灣5G 5G基地臺

加速5G網路覆蓋，電信三雄年底將合計蓋1萬座5G基地臺

臺灣5G即將正式啟用。前三大電信業者中華電信、遠傳電信、台灣大哥大先後都在6月獲得NCC許可，取得5G特許執照，至此三大電信都已完成了全部法定程序，待準備好就可以隨時開臺。延續4G競爭，外界預期，老大哥中華電信5G服務開臺將搶得第一，遠傳和台哥大則要爭取2、3名，預料6月底至7月之間就會開通5G服務。據了解，中華電信與遠傳目前皆已完成至少一千座5G基地臺，年底前還要擴大到3千座，至於台哥大目前也有數百個5G基地臺已布建完，年底更將加碼擴大到4千座，三家年底共蓋1萬座。

全球5G 5G商用

GSA公布最新5G商用市場報告，全球已逾40國家推出5G服務

根據全球行動通訊供應商協會（GSA）最新一份5G市場調查報告指出，截至5月，全球已有40個國家及地區推出符合3GPP標準的5G商用服務，比起3月新增2國。在這些國家及地區中，累計共有81家電信商已完成推出一項或多項5G服務，包括了5G行動服務、5G FWA或家用寬頻服務等。該報告也顯示，截至目前，在全球125個國家及地區中，多達386家電信營運商已宣布將投資5G，當中近半數5G投資集中4∼8 GHz的C波段（尤其是3.3GHz∼4.2GHz 的n77和3.3GHz∼3.8GHz 的n78重疊波段）來部署網路；其次則是24.25∼29.5 GHz毫米波頻段。GSA另一份5G裝置市場報告也顯示5G裝置數量成長迅速，到5月底，已有高達112款裝置支援5G，像是手機、筆電、平板、VR頭戴設備、5G Wi-Fi分享器、室內/外CPE、機器人、無人機等。

開放5G O-RAN聯盟

全球GSMA通訊協會與O-RAN聯盟強強聯手，要打造開放5G網路生態系統

過去主推開放RAN架構的O-RAN聯盟，近日更獲得了全球行動通訊產業利益代表的GSMA協會大力支持，該協會更宣布將與O-RAN結盟，未來將透過彼此協作，來打造一個更加開放的網路生態系統。1995年成立的GSMA協會，由近800家行動業者組成，成員更遍全球220多國，可以說是全球最大規模行動通訊產業協會，每年更負責統籌全球最重要的MWC大會。有了GSMA協會的協助，等於是替O-RAN聯盟打了一劑強心針，特別是在5G網路。GSMA首席技術長Alex Sinclair表示，當5G完全發揮長處，相較於第一代行動網路， 它對企業影響將遠遠高於消費市場，甚至將創造高達7,000億美元的市場價值。但要實現這樣服務市場，他認為，開放網路生態系的成形是關鍵。目前雙方已就建立互通性且開放式介面，與虛擬化RAN標準及產品落地展開合作。其中在開放式RAN產品與解決方案，裡面將採用了新的開放式虛擬化架構，並搭配軟硬體設計等。

日本樂天 虛擬化5G核網

日本樂天攜手NEC打造純虛擬化5GC核網，預計2021年商用

日本新進電信商樂天行動最近宣布，將與NEC聯手開發採用SA獨立組網架構的5G核心網路，也就是下一代5GC，用於自家5G網路服務。該公司更強調該核網將經過容器化，而且是一個純虛擬化的雲端原生5G網路，未來將透過樂天通訊平臺RCP提供。樂天行動不是首次與NEC合作，在這之前，雙方已在4G網路展開合作，包括BSS和OSS系統等，使用NEC相關技術，以支援該公司在4G網路營運。隨著5G時代來臨，雙方也決定擴大合作，未來樂天行動將採用NEC開發的5GC軟體，來建立樂天SA架構的5G核網，預計明年在日本推出其服務。而採用NSA架構的5G服務，可望在今年下半年推出。該公司也計畫將自家5GC核網變成產品銷往海外市場。

思科 5G戰略

思科揭露未來5G戰略布局，將押寶虛擬化RAN技術搶進5G新戰場

近日，在思科Cisco Live峰會後一場亞太線上媒體活動上，思科執行長Chuck Robbins揭露了未來5G戰略布局，將把重心放在虛擬化RAN（無線接取網路）技術搶進5G市場。有別於傳統無線電業務，ChuckRobbins認為，隨著軟體定義與虛擬化RAN發展越來越成熟，未來這種開放式RAN架構，有機會變成可行的部署方式，「這也是思科未來可以跨入的領域。」他說，將持續關注虛擬化RAN發展。思科目前也是O-RAN聯盟與開放RA N政策聯盟一員。現今思科在5G技術及產品方面，已涵蓋了從前端5G基地臺路由器，到後端骨幹核網採用的資料封包技術及路由平臺，以及協同作業軟體堆疊都有，去年更開始出售電信專屬晶片與路由器產品如Cisco8000等。他也透露，目前已與多家電信營運商緊密合作，包括加強5G安全性與協助其提供5G企業應用服務等。

開放RAN Nokia

Nokia加入Google、微軟為首的開放RAN政策聯盟，以支持5G開放網路發展

Nokia近日宣布已正式加入開放RAN政策聯盟（Open RAN Policy Coalition），成為第一家加入該聯盟的全球主要5G電信設備供應商。開放RAN政策聯盟是今年5月由Google、微軟、AWS、臉書等30多家科技公司及電信商成立的新聯盟，旨在促進政府政策以支持開放且互通性網路方案，並且致力於開放RAN的開發與採用。該聯盟希望通過開放RAN架構，從而實現網路彈性配置與模組化部署，如無線電、軟硬體，而不被特定廠商綁定。在加入該聯盟以後，Nokia表示，未來將與其他成員共同擬定包括支持開放無線網路研發的政策規範。除了開放RAN政策聯盟，目前以推動開放RAN為主的組織或聯盟，還有O-RAN聯盟與臉書TIP專案。Nokia全都加入，Ericsson僅加入O-RAN聯盟，至於華為均未加入。

資料來源：https://ithome.com.tw/news/138486?fbclid=IwAR0fuLejTzfq1WXD_nJfl7wVP215cexNnhH23wFCDkcL8t_LCoc4BKRJs3U