最近 lighttpd 不斷想辦法壓榨效率,利用各種方式想辦法增加 throughput。
先是在去年年底的時候發現 I/O block 的問題,在改用 Linux AIO 及 POSIX AIO 取代原來的 sync sendfile()
read()
後發現 throughput 增加了 80%:Async IO on Linux、lighty 1.5.0 and linux-aio、linux AIO and large files、PRE-RELEASE: lighttpd-1.5.0-r1477.tar.gz (POSIX AIO)。
然後覺得 FastCGI 的 overhead 太高,於是 (看起來) 想要用 shm 解決:Faster FastCGI、Faster Web 2.0。
再來就是把 dynamic page 的壓縮也實做出來了:Compression of dynamic content。
然後最近又發現丟小檔案時,stat()
因為會 block,所以 overhead 算是蠻重的,於是決定把 stat()
的 request 丟到 FastCGI 外面跑:Accelerating Small File-Transfers,而後來又發現用 Threading 會更快:Threaded stat()。
以這個速度發展下去,在 1.5 正式出版後,從 1.4.13 升級上來的重度使者應該會感覺到 lighttpd 的效率爆增,然後搞不太清楚發生什麼事情?XD
Update:sendfile()
to sync read()
...
原文並沒有說要取代 sendfile(), 而是在開檔的地方改用 AIO + mmap 減少 cpu 等待的時間
我看了他的測試方式, 實際上, 很少系統會一直存取新檔, 大部份的網站的熱門檔案(網頁,照片...) 這些常被存取的檔案, 幾乎都會被 OS 放到系統的 cache 裡, 如此一來, AIO 就討不到任何便宜了..