本文研究的是在海量靜態(tài)文件下，如何提高nginx的處理能力。在靜態(tài)文件數(shù)量不是很多的情況下，nginx處理靜態(tài)文件的能力極快，但是在海量的靜態(tài)文件下，nginx的處理能力就不那么樂觀，怎么提高nginx處理能力呢，當(dāng)然從系統(tǒng)角度，可以mount時(shí)對(duì)文件系統(tǒng)加noatime，以及采用目錄hash，再結(jié)合url rewrite等方式，可以適當(dāng)?shù)奶岣唿c(diǎn)性能，我這里介紹的是，通過將靜態(tài)文件存在leveldb的方式。

先說一下測(cè)試的環(huán)境，戴爾R710普通服務(wù)器，7200轉(zhuǎn)的普通硬盤，沒有做raid。拿了55萬張圖片，41G去盡可能模擬海量圖片的情形，當(dāng)然這個(gè)量級(jí)與一般公司的量級(jí)還差的太遠(yuǎn)，這里只測(cè)試，壓力工具用siege。

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

文件系統(tǒng)下nginx壓力測(cè)試：

這個(gè)能力會(huì)讓我們對(duì)nginx很失望，每秒約處理163個(gè)請(qǐng)求，平均每個(gè)請(qǐng)求耗時(shí)0.6s，吞吐不到12MB。問題不再于nginx，在于系統(tǒng)文件系統(tǒng)的io瓶頸，linux文件系統(tǒng)基于樹狀設(shè)計(jì)，加上硬盤本身的缺陷，使得文件系統(tǒng)的隨機(jī)io不高，當(dāng)文件數(shù)量不多，加上系統(tǒng)的cache，感覺不明顯，但文件數(shù)量上一個(gè)量級(jí)，文件系統(tǒng)的io將迅速成為系統(tǒng)中***的瓶頸。

怎樣去彌補(bǔ)文件系統(tǒng)自身的io不足，提高nginx的靜態(tài)處理能力，我一直在思考這個(gè)問題，現(xiàn)在nosql很火，我一直設(shè)想如是將數(shù)據(jù)全部存在 nosql里面，避免通過文件系統(tǒng)去查找文件，是否會(huì)提高nginx的處理能力呢，我把上面測(cè)試的41G的558397圖片全部存入google的 leveldb中，編寫一個(gè)nginx的leveldb模塊，讓nginx請(qǐng)求直接去查詢leveldb，再用上面同樣的方式去隨機(jī)測(cè)試，得到如下數(shù)據(jù)。

leveldb下nginx壓力測(cè)試：

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

我把我編寫的nginx模塊的hander部分貼出來，沒有做任何優(yōu)化和請(qǐng)求頭過濾。

編譯確保nginx正常鏈接到leveldb

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

補(bǔ)充一下采用目錄hash+url rewrite的測(cè)試結(jié)果，回答一下下面一個(gè)熱心朋友的疑問。在這里北游謝謝熱心的朋友參與和討論，我將保證每個(gè)人的提問我都必回，談?wù)勎业目捶?，也聽聽別人的看法，希望以此認(rèn)識(shí)更多的朋友，共同成長(zhǎng)。在這里要感謝開源中國(guó)社區(qū)給我們提供了一個(gè)這樣的交流討論平臺(tái)。

我這里圖片的命名，都是數(shù)字組成，為了讓每個(gè)目錄盡可能的分配均勻，我這里分二級(jí)目錄去hash,***級(jí)用文件名的第2位和第3位組成，第二級(jí)目錄名用第4位第5位第6位組成，這樣分成2層目錄，***層100個(gè)目錄，第2層1000個(gè)目錄，平均每個(gè)目錄約55個(gè)文件。

先準(zhǔn)備環(huán)境，如圖：

nginx的rewrite配置如圖：

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

數(shù)據(jù)我就不分析說了，與leveldb方式差距太大了。

原文鏈接：http://my.oschina.net/beiyou/blog/79646