nginx static module vs redis，誰更快？

nginx 提供的static module，使用了 sendfile 來避免 用戶態頻繁的系統調用，同時通過緩存fd來減輕系統在頻繁文件訪問時，維護file table的開銷。

redis 也可以用來做 static 文件的緩存，文件全部在內存里，速度很快

問題就是

nginx static module 快 還是 nginx + redis 快？

有人測過嗎？

首先這兩個的協議不一樣，如果客戶端只能用其中的一個，那麼快慢其實並不能對選擇起到幫助了。如果客戶端不挑協議並且完全不考慮內存消耗的成本的話，最終的效果要看具體情況了。

redis的數據全都是放在內存中的，而nginx要send出去的文件可能是冷的尚未被操作系統cache住的。這時sendfile雖然可以避免從用戶態到內核態的這次數據拷貝，但是內核需要從存儲設備上讀取出來對應文件的內容，這些都是需要消耗時間的。如果文件保存在機械盤上那麼響應時間還嚴重依賴於訪問特性，對於大量小文件來說這裡會有很多的隨機讀從而嚴重影響到性能。但是從另外一個方面看如果不在乎內存消耗的話，那麼nginx所在的機器內存同樣也會非常大，經過初次訪問熱過數據後再次sendfile的時候就和redis類似直接可以從內存讀取內容進行發送了只不過這次response body部分是直接從kernel管理的cache內存發送的。在這種數據同樣都已經存在於內存中的情況下，如果serve的都是很小的文件的話那麼從用戶態到內核態的拷貝數據的代價並不會很大，再考慮到其它實現方面的各種細節差別，兩者的性能差距有可能會很微觀。

最後說下個人感覺，也未必正確吧。從serve小文件這件事情來看，如果文件數量並不是很巨大並且內存cpu也很充足的情況下，可能會優選nginx，畢竟http協議現成的客戶端太多了會更容易，性能在這種情況下應該也不會有太顯著的差別。而且nginx還可以有多個worker進程來利用多個核心，redis就還得考慮啟動多個redis實例利用sharding來充分利用多個核心這又是一個需要操心的點。