建站
咨詢
售后
建站咨詢
新聞中心
本文研究的是在海量靜態(tài)文件下，如何提高nginx的處理能力。在靜態(tài)文件數(shù)量不是很多的情況下，nginx處理靜態(tài)文件的能力極快，但是在海量的靜態(tài)文件下，nginx的處理能力就不那么樂觀，怎么提高nginx處理能力呢，當然從系統(tǒng)角度，可以mount時對文件系統(tǒng)加noatime，以及采用目錄hash，再結(jié)合url rewrite等方式，可以適當?shù)奶岣唿c性能，我這里介紹的是，通過將靜態(tài)文件存在leveldb的方式。
我們提供的服務(wù)有：做網(wǎng)站、成都網(wǎng)站設(shè)計、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、皇姑ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學管理、有技術(shù)的皇姑網(wǎng)站制作公司
先說一下測試的環(huán)境，戴爾R710普通服務(wù)器，7200轉(zhuǎn)的普通硬盤，沒有做raid。拿了55萬張圖片，41G去盡可能模擬海量圖片的情形，當然這個量級與一般公司的量級還差的太遠，這里只測試，壓力工具用siege。
- 命令：siege -c 100 -b -i -r 100 -f /tmp/urlll
文件系統(tǒng)下nginx壓力測試：
這個能力會讓我們對nginx很失望，每秒約處理163個請求，平均每個請求耗時0.6s，吞吐不到12MB。問題不再于nginx，在于系統(tǒng)文件系統(tǒng)的io瓶頸，linux文件系統(tǒng)基于樹狀設(shè)計，加上硬盤本身的缺陷，使得文件系統(tǒng)的隨機io不高，當文件數(shù)量不多，加上系統(tǒng)的cache，感覺不明顯，但文件數(shù)量上一個量級，文件系統(tǒng)的io將迅速成為系統(tǒng)中***的瓶頸。
怎樣去彌補文件系統(tǒng)自身的io不足，提高nginx的靜態(tài)處理能力，我一直在思考這個問題，現(xiàn)在nosql很火，我一直設(shè)想如是將數(shù)據(jù)全部存在 nosql里面，避免通過文件系統(tǒng)去查找文件，是否會提高nginx的處理能力呢，我把上面測試的41G的558397圖片全部存入google的 leveldb中，編寫一個nginx的leveldb模塊，讓nginx請求直接去查詢leveldb，再用上面同樣的方式去隨機測試，得到如下數(shù)據(jù)。
leveldb下nginx壓力測試：
與上面的性能數(shù)據(jù)相比，每秒的處理能力由163提高到了380，平均每個request耗時由0.6s降到了0.25s，吞吐由12MB提高到了27MB?？傮w至少提高了近2~3倍的處理能力。如果數(shù)據(jù)量級更大的話，我估計性能提升的倍數(shù)更高。
我把我編寫的nginx模塊的hander部分貼出來，沒有做任何優(yōu)化和請求頭過濾。
編譯確保nginx正常鏈接到leveldb
有興趣的朋友可以繼續(xù)研究有沒有更好的方法，歡迎交流。
補充一下采用目錄hash+url rewrite的測試結(jié)果，回答一下下面一個熱心朋友的疑問。在這里北游謝謝熱心的朋友參與和討論，我將保證每個人的提問我都必回，談?wù)勎业目捶?，也聽聽別人的看法，希望以此認識更多的朋友，共同成長。在這里要感謝開源中國社區(qū)給我們提供了一個這樣的交流討論平臺。
我這里圖片的命名，都是數(shù)字組成，為了讓每個目錄盡可能的分配均勻，我這里分二級目錄去hash,***級用文件名的第2位和第3位組成，第二級目錄名用第4位第5位第6位組成，這樣分成2層目錄，***層100個目錄，第2層1000個目錄，平均每個目錄約55個文件。
先準備環(huán)境，如圖：
nginx的rewrite配置如圖：
同樣用bin/siege -c 100 -b -i -r 100 -f /tmp/urlll，測試結(jié)果如下:
數(shù)據(jù)我就不分析說了，與leveldb方式差距太大了。
原文鏈接：http://my.oschina.net/beiyou/blog/79646
當前題目：Nginx性能改進一例
網(wǎng)站路徑：http://m.5511xx.com/article/cdcggdg.html
