read 一開始並不會到 user space 一定是在 kernel 處理,所以 user space 必須去 kernel 讀取網路封包,接著進行某些加工後,再 write 回 kernel,在透過驅動程式將封包交給 client 端(網路瀏覽器、社群軟體)。
所以這過程有大量的資料複製要處理。
sendfile 合併了傳統的 read 及 write。原先的步驟是從檔案系統讀取內容傳到 user space,再將資料從 user space 傳到 kernel,合併後的優點是 user space 只要檢查執行結果就好。所以如今的網路伺服器幾乎都在 user space 實作。
io_uring 是 Linux 的明星技術,受到了廣泛的關注。
epoll 這個系統呼叫可監控多個事件。但本質上是同步的,而 io_uring 是 AIO。
Ftrace 也是動態追蹤 linux 核心的工具,在授課老師撰寫的排程器書籍第六章有相關介紹,主要用於追蹤特定時間段,kernel 某部份的程式碼執行時間
kecho
是運作在 kernel 的 server。
將專案 clone 下來後,使用 make 進行編譯。
接著要掛載 kecho.ko
檔。
接著可透過下列命令來檢查是否運作:
接著輸入下方命令可以離開:
其中 ^] 並非直接輸入,而是按下 ctrl+]
專案中的 ./bench 可用來效能分析,會將結果輸出至 bench.txt
user-echo-server
是運作在 user space 的 server
使用之前要先將 kecho 解除:
再執行一次 make check
:
上述進度條的相關實作在 scripts/util.sh
中
drop-tcp-socket
這也是一個核心模組,若 kecho 崩潰,但沒有釋放其佔用的埠,可用將指定的埠關掉。
seHTTPd
將專案 clone 下來後,主要要看的程式碼在 /src 中
epoll 效率很高,為何還要 select 及 poll??
使用場景不同,如同排序演算法,
編譯完後使用下列命令執行伺服器:
開啟另一個終端機視窗,輸入下列命令可以監看伺服器的效能:
這個跑超級慢。
結果如下:
而 httperf 也可作為伺服器效能的評估工具。
須從原始程式碼編譯。
在 lab0-c 評估常數時間時,可以將 outlier 去除,但反映在網頁伺服器上,這個議題須更慎重考慮。
BPF 程式一但編譯後變成了 byte code,就會注入到 Linux Kernel。
一樣先使用 make 編譯,編譯完成後要掛載,命令如下:
同時也可以自行指令埠要用幾號:
接著使用下列命令可以建立客戶端連線:
用下方命令可以觀測 port 狀況:
我還不知道為啥是觀測 8081,因為上面指定的是 1999。
重新看了一下影片,老師有先解除掛載,然後再重新掛載一次,並且這次沒有指定 port。不過當我進行一樣的操作時,出現下方資訊:
還不確定問題所在。
接著可以使用 htstress
進行壓力測試:
結果如下:
下方命令可查看與模組相關的 kernel thread:
改進網頁伺服器性能,可以透過 ftrace 來追蹤,首先要先確認目前系統是否有 ftrace:
接著是結合剛剛的壓力測試去撰寫簡單的測試腳本:
將其命名為 test.sh
,可以以下列命令執行:
每秒可以回應將近 7000 個連線,相比剛剛少了很多。
接著去追蹤 ftrace
的結果:
會發現花費許多時間在:
從這些花費時間較長的函式去改善,就有相當大的優化空間。
此為本作業重要的要求。
ftrace
還能追蹤函式的階層關係,我還沒詳細去操作過。