Search
Latency 與 Bandwidth 到底哪一個是真正影響儲存效能的因素呢？說到底，關鍵還是在於應用系統的行為。
舉例來說，如果要觀看 4K 的奧運轉播，那麼可能要 100M 的頻寬才會有比較流暢的觀賞體驗；但如果是在號子進出當沖，5 個咩的頻寬就足足有餘了！再說，如果不是大量交易集中型應用，即使把回應時間大幅度的從 2ms 降低至 0.02ms，對連線進來的使用者來說，可能也是完全無感的，因為光網路上的延遲就遠遠超過這個數字！
不過，快閃儲存的低延遲對於老舊系統在效能的提升上，肯定是有所 助益的！
ref: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf
本篇文章是探討一個前後端互相合作的設計模式，Backend For Frontend 簡稱為 BFF。
文章開頭，作者舉了一個常見的應用情境，假設團隊需要基於微服務的概念去設計一套電商系統，背後服務包括了購物車，訂單，產品，顧客...等不同類型的資料。
但是很容易後端所回傳的資料格式並不能完全直接符合前端的需求，這意味前端必須要維護一套邏輯來轉換資料格式來符合其需求。
基於這種情況，作者希望將前端這些轉換格式的邏輯給抽出來並且移動一個中間層來進行處理，而這個中間層也就是所謂的 BFF。
當前端需要請求一些資料時，前端會對 BFF 去發送 API，而此時 BFF 會執行下列行為
1. 呼叫對應的 backend 服務來獲得需要的資料
2. 根據前端的需求將獲得的資料進行格式轉換
3. 將轉換後的格式回傳前端
這種架構下，能夠讓前端的程式邏輯更為簡單與乾淨
接者作者針對 BFF 的架構又探討了幾個問題，分別
The role of a BFF
1. BFF 單純就是一個前後端中間的轉換介面
2. 前端 Team 要負責維護這個 BFF 的應用程式
3. 每個 BFF 就是針對一個前端，一個 UI 去設定，同時盡可能地讓前端程式碼保持單純與專注
Will this increase latency?
由於 BFF 就是一個前後端中間的轉換層，這是否意味所有請求都會需要花費更長的時間來處理，
答案是沒錯，每個請求只要經過愈多的節點整個花費時間會增加是不可避免的。
不過作者認為這個帶來的影響微乎其微，特別是當瀏覽器介面本身需要需要跟眾多沒有針對前端最佳化的服務取得資料時，BFF 帶來的影響基本上可以忽略。
此外，作者認為透過 BFF 的架構可以讓前端更容易得基於批次的概念來一口氣呼叫眾多後端服務同時於一個 reply 中取得全部所需的資料，甚至直接得更為方便呈現的資料格式。
作者提到這個特色針對 2G/3G 這種本身需要花上數秒鐘才可以建立連線的網路情況來說特別有效，減少向後建立連線的數量，反而能夠讓前端更有效率地去呈現畫面。
When to use a BFF for your applications
如同其他眾多的設計模式一樣， 使用 BFF 也是要依據團隊的使用情境與架構來判別。 假設團隊的應用程式是一個 monolithic 的架構，則 BFF 基本上幫不上什麼忙，帶來的好處微乎其微。
不過如果是基於微服務的架構的話，則 BFF 就有機會可以幫上忙。
文章中還有針對 BFF 的架構圖是以及其他相關好處，譬如
1. Separation of concerns
2. Easier to maintain and modify APIs
3. Better error handling in the frontend
4. Multiple device types can call the backend in parallel
5. Better security
6. Shared team ownership of components
有興趣的可以參考看看原文
本文延續前篇效能校正的經驗談，上篇文章探討了關於系統呼叫, iptables 可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。
Perfect Locality
預設情況下， Linux Kernel 會盡量平均地將請求給分配到所有的處理佇列，譬如 network queues, processes, CPUS. 大部分情況下這種機制運作良好不會有太多問題，不過如果今天要追求的不單單只是好的效能，而是極致的效能，則 locality 這個概念就要特別的去注意。
這篇文章中提到很多不同的方式，包含了 CPU Pinning, Receive Side Scaling(RSS), Transmit Packet Sterring(XPS)等，其實用比較簡單的介紹方式就是，希望可以使用固定的 CPU 來處理一條連線上的所有封包(進出)，這樣帶來的好處有
1. CPU Cache 可以盡可能的去使用，減少各種 miss 產生的成本
2. 減少 context switch 帶來的成本
3. 減少跨 CPU 之間交換資料帶來的成本
4. 減少 lock 之間帶來的成本
除了 CPU Pin, RSS, XPS 外，還有 irqbalance, smp_affinity_list 等相關的概念需要一併學習，對於這個概念有興趣的讀者非常歡迎去找尋這類型的資料
接者是 SO_REUSEPORT 這個參數，創建 Socket 時使用這個參數能夠使得多個 Process 共用一個連接埠，底層 Kernel 會針對 src/dst{ip/port} 來產生對應的 Hash，並且決定當前封包要送給哪一個 Process。
這個方式搭配前述各種 CPU Pin, 中斷的最佳化則會遇到問題，因為可能底層將該封包送到 CPU2 結果這個函式又把封包重新分配到 CPU0, 這樣就導致該連線要跨 CPU 處理了。
為了解決這個問題， Linux Kernel 4.6 後有新的參數 SO_ATTACH_REUSEPORT_CBPF，使用者可以自行撰寫 BPF 的程式來決定如何分配封包。作者根據這過想法撰寫了一個 BPF 的程式，來確保這個機制可以與前述的最佳化穩定運作。
這次的最佳化帶來的 38% 的成長，這時候的封包處理能力從 603k req/s 提升到 834k req/s
原文中關於這次的最佳化還有一些後續探討，有興趣的可以閱讀
Interrupt Optimizations
當封包透過網路送到網卡後，網卡必須要通知 OS 讓它知道有封包來了，要記得處理。一切處理完畢後網卡就可以繼續等待新的封包過來並且再次發送中斷給 OS 處理封包。這個流程大部分情況也是運作良好，不過當有大量的封包不停傳送來時，頻繁的中斷其實也是會造成不小的額外成本。
為了解決這個問題，目前比較嶄新的網卡都有支援中斷聚合等功能，透過這個功能可以延後中斷一個小週期，而該週期內收到的所有封包只需要透過一次的中斷就可以來處理，藉此降低中斷的次數。更為進階的網卡甚至支援動態自行調整該週期的時間，譬如當網路空閒時，減少週期使得每個封包能夠盡快的發送中斷被處理，而當網路流量很大時則會加大該該週期時間來更有效地處理封包。
註: AWS ENA 有支持這種動態調整的機制
作者基於 AWS 開啟動態調整收端中斷時間的功能，整個效能提升了 14%，從 834k req/s 提升到 955k req/s。作者說這次的調整可以說是整篇文章中幾個非常強的改動，改動的地方少，效能提升明顯，同時背後的隱憂與限制也少。
除了上述中斷的方式外，另外一種則是透過 Busy Polling 這種針對低延遲性的方式。預設情況下其允訓設定為 blocked 的 socket 能夠消耗額外的 CPU Cycle 來讀取接下來的封包，可以將其想成一成一種混合體，當底層網卡告訴我有資料要讀取時，我預期接下來還會有更多的資料，因此我就透過輪詢的方式去多問幾個封包。
由於作者的應用程式是使用 non-blocking 的方式去讀寫封包，所以預設的方式是沒有辦法使用的。而該應用程式又是使用 epoll 來進行底層封包的讀寫。 epoll 於 kenel 4.12 後正式支援 busy polling 的方式，所以這部分就沒有太大的問題。文章中有滿多關於 busy_poll 的一些參數調整。
將這兩個機制給整合後，整體的效能提升達到 28%，從 834k req/s 到達 1060k req/s，同時 99%的 latency 也從 361μs 下降到 292μs.
同時這兩個機制導入後，整個系統每秒產生的硬體中斷數量也從 183k 降到 16k。 Context switches 的數字也從 6k 下降到 1k 左右。
下篇文章會繼續從剩下的三個最佳化策略繼續介紹
https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/
azure-docs.zh-tw/articles/virtual-network/virtual-network-test-latency.md ... 測試Azure 虛擬網路中的Azure 虛擬機器網路延遲|Microsoft Docs. ... <看更多>
latency網路 在 這裡介紹網路的延遲（Latency）與頻寬（Bandwidth）是什麼 的推薦與評價
這裡是凍仁與Ubuntu 一起學習成長的筆記，文章大多與 GNU/Linux 及自由軟體(Free Software) 有關，若有相關問題歡迎來信。 ... <看更多>