為什麼80%的碼農都做不了架構師？>>>

本文研究的是在海量靜態檔案下，如何提高nginx的處理能力。在靜態檔案數量不是很多的情況下，nginx處理靜態檔案的能力極快，但是在海量的靜態檔案下，nginx的處理能力就不那麼樂觀，怎麼提高nginx處理能力呢，當然從系統角度，可以mount時對檔案系統加noatime，以及採用目錄hash，再結合url rewrite等方式，可以適當的提高點效能，我這裡介紹的是，通過將靜態檔案存在leveldb的方式。

先說一下測試的環境，戴爾R710普通伺服器，7200轉的普通硬碟，沒有做raid。拿了55萬張圖片，41G去儘可能模擬海量圖片的情形，當然這個量級與一般公司的量級還差的太遠，這裡只測試，壓力工具用siege。

命令：siege -c 100 -b -i -r 100 -f /tmp/urlll

檔案系統下nginx壓力測試：

這個能力會讓我們對nginx很失望，每秒約處理163個請求，平均每個請求耗時0.6s，吞吐不到12MB。問題不再於nginx，在於系統檔案系統的io瓶頸，linux檔案系統基於樹狀設計，加上硬碟本身的缺陷，使得檔案系統的隨機io不高，當檔案數量不多，加上系統的cache，感覺不明顯，但檔案數量上一個量級，檔案系統的io將迅速成為系統中最大的瓶頸。

怎樣去彌補檔案系統自身的io不足，提高nginx的靜態處理能力，我一直在思考這個問題，現在nosql很火，我一直設想如是將資料全部存在nosql裡面，避免通過檔案系統去查詢檔案，是否會提高nginx的處理能力呢，我把上面測試的41G的558397圖片全部存入google的leveldb中，編寫一個nginx的leveldb模組，讓nginx請求直接去查詢leveldb，再用上面同樣的方式去隨機測試，得到如下資料。

leveldb下nginx壓力測試：

與上面的效能資料相比，每秒的處理能力由163提高到了380，平均每個request耗時由0.6s降到了0.25s，吞吐由12MB提高到了27MB。總體至少提高了近2~3倍的處理能力。如果資料量級更大的話，我估計效能提升的倍數更高。

我把我編寫的nginx模組的hander部分貼出來，沒有做任何優化和請求頭過濾。

編譯確保nginx正常連結到leveldb

有興趣的朋友可以繼續研究有沒有更好的方法，歡迎交流。

補充一下采用目錄hash+url rewrite的測試結果，回答一下下面一個熱心朋友的疑問。在這裡北遊謝謝熱心的朋友參與和討論，我將保證每個人的提問我都必回，談談我的看法，也聽聽別人的看法，希望以此認識更多的朋友，共同成長。在這裡要感謝開源中國社群給我們提供了一個這樣的交流討論平臺。

nginx的rewrite配置如圖：

同樣用bin/siege -c 100 -b -i -r 100 -f /tmp/urlll，測試結果如下:

資料我就不分析說了，與leveldb方式差距太大了。

轉載於:https://my.oschina.net/beiyou/blog/79646