本文延續前篇效能校正的經驗談，上篇文章探討了關於系統呼叫, 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/

大家只要好好觀察、紀錄或感受一下，當你有個想法想要嘗試看看，或是從 stackoverflow, Google 找到了某個 sample code, 解決方案，從有想法到實現完成，並確認執行是否正確、是否符合你的期待，你需要花多少時間？

這些時間都只是在「實現想法」而已，如果思考是一條 thread, 這一條 thread 就只能等到你 實現的那一條 thread 完成任務，才能再切回來，繼續往下想，或是想其他的解決方案。

思考這條 thread 等待越久，context switch 成本就越高，被 interrupt 導致你原本腦袋裡面的 memory 就會被刷到 swap disk 空間，到時要拉回來就更容易漏、要花更多時間恢復。

從有想法到驗證想法是否可行時間越長，你能嘗試的解決方案就越少。在現代的軟體開發，「剛好才是最好」，而所謂的剛好，通常就是從好幾種解決方案裡面挑出來一個「最合適解」，要嘗試好幾種解決方案是很花時間的。

而你嘗試過的解決方案越多，學到的東西就越多，不同 context 你的 option 就會比其他人多很多可以選。

大家一直拿來當笑話的「出張嘴寫程式比較快」，有沒有想過想法到哪，程式碼就長到哪的境界，這是個值得追求到境界。

當能最小化「實現想法、驗證想法」需要花費的時間時，你就更有機會與時間去強化、改善你思考的速度、廣度、深度，這樣才會是一個正向的增強迴圈。

By the way, ATDD/TDD 就是在縮短驗證想法的最有力方式，而且是「持續平緩驗證想法所需要的時間」，不會因為功能越來越多，系統越來越大而幾何指數增加驗證時間。

時間是最可貴的資源，人類的大腦跟思考運作，是看到東西就會產生更多的 feedback 刺激，幫助你產生更深入、有效的想法。這中間會有不斷不斷的 IPO(input/process/output, 加上 feedback），來讓你的軟體更接近你理想的狀態。

就像很多基本功深厚的開發人員，他們寫完自己的程式碼之後，就很自然地進行多次 code review 跟 refactor (沒有測試保護，沒法安心跟迅速 重構設計的），有程式碼出來，才會知道怎麼調整設計更好、更簡單，這些東西很多是無法在一開始就想得到的。

你這次想不到，但這次學到的東西下次就可以用，但下次仍然會有你想不到的東西，等到你做出來才會想得到，這就是軟體開發的宿命，也是正常現象。我們能運用這種自然現象，來不斷增強自己的功力與學習速度。

結論，這功夫練好，你省下來的時間，就會讓你「學什麼都快」。

不然我也沒法子在短時間裡面，能應用那麼多不一樣的 IDE, 以不一樣的程式語言特性來設計上課的內容。

因為我每次只需要去嘗試不一樣的地方，而我試錯調整的速度是別人的好幾倍快，自然上手快，自然面對一個問題，不同的限制跟考量，口袋都有好幾種解決方案等著。

#極速開發，讓你能省下來更多時間進行學習跟改善，就能賺到更多時間，接著把時間換回來巨大的商業價值。

想像一下你現在一年多少錢，換算下來每個時間單位報酬是多少錢，而現在省下來的時間，放到十年後的你，這些時間單位所換回來的單位報酬有多高。

我是不知道是不是一體適用，但我現在的時間報酬（以年來看更準一點），是我第一份工作的20倍以上。

越晚學會，你能賺到的時間單位就越少。（當然啦，如果省下來的時間沒有好好運用，那錢也不會從天上掉下來，遊民每天也有很多時間的）