Nginx“線程池模式”探討；據說性能提高了9倍
相對于Apache的同步IO模型，Nginx由于采用了NIO的緣故，性能上碾壓前者。Nginx是輕量級的，占用的系統資源更少，天然支持高并發。
今天我們就簡單的討論一下nginx的線程模型。注意不是進程模型哦。
nginx的IO模型，大家應該都有所了解。簡單而言，就是一個master進程和多個worker進程(進程數由配置決定);master進程負責accept請求并隊列化，最后轉發給worker進程并由其進行請求處理和響應的整個過程。
nginx是以多進程模式運行的。nginx在1.7.11版本提供了多線程特性(multi-threading)，不過這個多線程僅用在aio模型中對本地文件的操作上，出發點就是以非阻塞模式，來提高文件IO的效率和并發能力。
所以這個多線程，并不是nginx通過多線程的方式處理proxy request(這部分是通過epoll模式)，而是用來處理本地的一些靜態文件。
這里涉及到幾個基本指令：sendfile、aio和directio，它們均與本地文件的操作有關，接下來我們分別看看它的意義。
sendfile
這個指令與系統函數sendfile()具有相同的語義，sendfile的目的就是提高本地文件通過socket發送的效率。官方的博客介紹了如何利用nginx 線程池aio，實現9倍的性能。
它還有一個比較好記的名稱，叫做零拷貝。那與傳統的文件讀取然后發送到網絡上，有什么區別呢?
磁盤、網絡驅動器、內存是三種不同的傳輸介質，如果從本地讀取一個文件并通過socket發送出去，通常情況下是進過如下幾個步驟：
- 磁盤驅動器從根據CPU的調度，從磁盤讀取一定長度(chunk)的字節數據
- 字節數據copy到內核內存中
- 將內核內存中的數據copy到進程工作區內存
- 進程通過socket將數據copy到網絡驅動器緩存， 并通過相應的傳輸協議發送出去。
可以看到，數據的發送過程涉及到多次copy，這受限于計算機系統的設計問題。
sendfile的主要出發點，就是要減少數據的copy以提高發送效率，sendfile是linux系統級的調用，socket可以通過DMA(直接內存訪問)方式直接訪問文件數據，并通過傳輸協議發送，減少了2次數據copy(磁盤到內核，內核到工作區)。
sendfile_max_chunk參數用于限定每次sendfile()調用發送的最大數據尺寸，如果不限制大小的話，將會獨占整個worker進程，默認為“無限制”。這也太霸道了。
對于nginx而言，代理靜態本地的靜態文件資源(通常是小文件)將是非常高效的，建議對一些靜態文件比如html、圖片等，開啟此參數。
- location /video {
- sendfile on;
- sendfile_max_chunk 128k;
- aio on;
- }
directio
這個指令用于開啟對O_DIRECT標記(BSD，linux)的使用，對應directio()這個系統調用。
此參數是針對大文件而設定的，sendfile針對的是小文件。通過directio可以指定限定的尺寸大小，對于超過此size的文件，將會使用directio(而不再使用sendfile)。
根據directio的設計初衷，它具備sendfile的基本原理，只是不使用內核cache，而是直接使用DMA，而且使用之后內存cache(頁對齊部分)也將被釋放。
因此directio通常適用于大文件讀取，而且通常讀取頻率很低。因為對于高頻的讀取，它并不能提高效率(因為它不會重用cache，而是每次都DMA)。由于存在性能權衡問題，此參數默認為off。
- location /video {
- sendfile on;
- directio 8m;
- aio on;
- }
aio
談到aio模型，其實語義也基本相同，就是異步文件IO，nginx默認關閉此特性，它需要在高版本的linux平臺上才支持(2.6.22+)。
在linux上，directio只能讀取基于512字節邊界對齊的blocks，文件結束的那些未對齊的block將使用阻塞模式讀取。
同樣，如果文件在開頭沒有對齊，整個文件都將阻塞式讀取。這里所謂的對齊，就是文件數據在內存頁中的cache情況。
當aio和sendfile都開啟時，將會對那些size大于directio設定值的文件使用aio機制：即當小于directio設定值的文件將直接使用sendfile(aio不參與)。
aio，簡單而言，就是使用多線程異步模式讀取較大的文件，以提高IO效率，但是事實上可能并沒有任何提高。因為大文件的讀取，并不能使用cache、而且本身也是耗時的，即使是多線程，對于request的等待時間也是無法預估的，特別是并發請求較高的時候。但是aio能夠提高IO的并發能力，這個是確定的。
默認情況下，多線程模式是關閉的，我們需要通過--with-threads配置來開啟，此特性盡在支持epoll、kqueue的平臺上兼容。對于線程池的設置，我們可以通過thread_pool來聲明，并在aio指令中指定。
我們的配置文件近一步豐富了一些。
- thread_pool default_pool threads=16;##main上下文
- ...
- location /video {
- sendfile on;
- sendfile_max_chunk 128k;
- directio 8M;
- aio threads=default_pool;
- }
當線程池中所有的線程都處于busy狀態，那么新的task請求將會加入到等待隊列。我們可以在thread_pool中使用max_queue參數來指定隊列的大小，默認隊列大小為65536，當隊列已滿后續的請求將會拋出error。
END
nginx官方宣稱使用多線程模式，在aio讀取文件場景下，性能有9倍的提升，但我還是對這個測試具有一定懷疑態度。
多線程 + aio在一定程度的確可以提高文件IO的讀取性能，但是對于大文件而言，這似乎并沒有想象的那么優秀。這受制于linux平臺底層的本身特性，除非nginx自己對文件cache做了額外的操作。
到目前為止，xjjdog仍有以下建議(供參考)：
- 對于小文件的靜態代理，我們應該開啟sendfile，這對性能的提升是顯著的。
- 對于大文件讀取(低頻)，我們可以嘗試開啟aio、directio，在提升并發能力的前提下，關注request的實際響應效率;既然官方推薦這么用，我們可以報以嘗試的態度。
- 對于高頻大文件讀取，aio、directio的性能或許提升并不顯著，但應該不會降低性能。
