本篇文章是個經驗談，作者想要聊聊是如何將一個 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/

[好文分享] Visual Studio.NET 2010, 2012, 2013, 2015 差異比較表
( #ProgrammingTools #IDE #VisualStudioNET )

http://goo.gl/p3lqMk

我個人雖然從 2002 年開始就不用 Visual Studio.NET 了，不過我以前可是該軟體的粉絲呢！若有人問：「學程式該裝什麼軟體？」我二話不說，一定推薦 Visual Studio.NET。今天看到寫的這麼不錯的比較表，想說推薦給工作上有需要的網友們看，所以還是寫上來提供給大家了！

Visual Studio.NET 的好處，就是「功能完整強大」！很多像原始碼瀏覽查找、版本管理比較、跨檔案/專案的重構（Refactoring）... 它都提供。而且都做得很貼心、很順手。如果您工作上是靠 C#、VB、或 C++ 為生，而且成果多限制執行於 MS-Windows，這套還是很推的！

Visual Studio.NET...該說壞處嗎？好吧！應該說是我「個人考量」比較準確...有幾點：

1. 比較難跨平台使用（如：用於 Linux、Mac...我個人工作常常橫跨桌機三大平台 + 手機兩大平台...啥？手機有三大平台？還加上 Windows Phone？那是什麼...？ XD）。雖說套用 WINE 或虛擬機等軟體，勉強還是可以跑，但這樣就不順手了。

2. 安裝時比較肥大（我從 2002 年做嵌入式韌體開發後，因為嵌入式硬體運算能力不是很好，故開始崇尚 vim + gcc + gdb 這類在命令列模式下也能活的小軟體。很類似廚師高手只用「圓鍋、湯杓、菜刀」三樣工具就能做出任何菜色那種哲學）。

3. 某些我要的高級功能是要付錢的（不是說我吝嗇付錢，事實上每年我花在買軟體上的錢也有將近台幣 3~5 萬元。但若靠 vim + gcc + gdb 能做出相同結果，實在很難吸引我付錢）

以上針對程式開發工具使用心得，跟大家交換一點意見。您喜歡用哪種開發工具呢？歡迎留言在下面，好讓我跟您聊一聊喔！

不知道大家有沒有注意我在這篇文章開始做的一點小改變？是的！我開始加上「Hash Tag（#）」了！這可以讓您點擊某個標籤，就列出所有類似的文章喔（不止我的文章，也能撈到別人寫的相關文章）！希望這一點點小進步，可以讓您將來看文章時更方便！

喜歡這篇文章嗎？也有 Visual Studio.NET 同好嗎？歡迎把這篇文章轉分享給您的 Facebook 朋友喔！

----
2015/10/06 13:20 補註：

經網友指正，我的配圖有兩個容易誤導大家的地方：

1. 最左邊的 logo 是最新的，但我卻把比較舊的年份 2010 寫在最左方，容易讓人認為左邊的 logo 是最舊的。

2. 最右邊的 logo 並非 Visual Studio.NET 2010，而是 2008 的。

特此更正！也謝謝網友指教，造成不便請多諒解！

想在 30 分鐘內學會 Git 嗎？看這裡就對了！

Git 是一種「原始碼版本控制」軟體，它可以儲存原始碼每個版本之間的差異，然後您可以要求「時光回溯」到任何指定的版本。這可以防止一天到晚改規格的客戶或老闆，在您辛苦更動原始碼後，來一句要命的：「還是之前的那一版比較好」。我個人認為，它是程式設計中，最重要的 7 大軟體之一（文字編輯器、編譯器、版本控制器、自動化建構系統、單元測試軟體、環境佈建系統、與除錯器）。

這類「版本控制軟體」，依照流行先後，著名的有 CVS、Subversion、與 Git。目前最流行的版本控制軟體是「Git」，流行原因多多少少是因為 Linux 核心（Linux Kernel）原始碼，就是用這套軟體保持各個版本差異的。不少公司也要求程式設計師寫好原始碼後，一律都得回存 Git 系統才算完工，不能只是存在私人的硬碟就了事。所以 Git 就變成業界必備的軟體之一。

補習班常常有同學問我，有沒有那種很簡單的 Git 說明書，不用講太深，但要在 30 ~ 60 分鐘內就掌握常用功能的教材？之前一直找不到，不過今天幫大家找到了！還有中文版喔！叫做「Git 簡明指南」。鏈結如下：

https://rogerdudler.github.io/git-guide/index.zh.html

其實它的原文名稱有點好玩：「Git - The Simple Guide, No Deep Shit!」。這類標題通常能騷動我個性中愛作怪的小惡魔，讓我會心一笑後點進去看看。看完後，果然「一點點深的便便」都沒有... XD 還有中文版（簡中）！心想這麼讚的東西不介紹怎麼行！就花時間寫了這一篇。

希望今天的分享對各位的日常工作有幫助！我也很鼓勵大家能找到適合自己的「七大系統」，把它弄熟。畢竟「工欲善其事，必先利其器」嘛！我個人習慣使用的七大系統，也列在底下讓大家參考：

1. 文字編輯器：vim。不好學，但游標移動速度與文字操控能力超快！
2. 編譯器：gcc。因為我寫 C 語言比較多，所以用 gcc。
3. 版本控制器：git。其實我之前是熟 subversion。不過 git 也很好用喔！
4. 自動化建構系統：make。可以把編譯、安裝...等囉哩八唆的指令濃縮成一個簡稱（如：build, install...等）。打完按下 enter 後就可以去泡咖啡了！還能偵測哪些原始碼已經編譯過，不需重新編譯已縮短作業時間。
5. 單元測試軟體：CUnit。嚴格來說，這算一套「函式庫」，可以針對你寫好的原始碼做測試。由於我寫 C 較多，所以用 CUnit。如果您寫的程式碼是 Java 或其它，可能得找相對應的測試軟體。
6. 環境佈建軟體：VirtualBox。用它的原因是 Win, Mac, Linux 全平台都支援。我會把程式設計環境灌好後的 VirtualBox 映像檔保存好，每次要乾淨環境就 new 一個新的虛擬機起來。最近迷上 Vagrant，想知道 Vagrant 是什麼的可以看這篇： http://goo.gl/29mBs9
7. 除錯器：gdb。雖然是文字介面，但連線到運算能力很差的開發板上想除錯，也只有 gdb 跑得動。用久了也習慣了。

其實最近還想加上第八項「(8) 軟體部署系統：Docker」，不過還在研究，也還沒熟悉。等熟悉了再跟大家報告。 :-)

如果覺得文章不錯，還煩請各位不吝按讚打賞或分享一下喔！ m(^ ^)m