wget
解壓之後進入解壓目錄進行編譯引數配置
./configure --prefix=/data/soft/openresty --user=nginx --group=nginx
以上編譯引數可根據自己的實際需求調整，./configure --help 檢視引數
make & make install 編譯安裝
安裝後的目錄介紹
了解openresty之前，我們先熟悉下nginx對請求的處理過程。
nginx接收到客戶端的請求之後，對請求的處理，是分階段的，總共有11個
接收完請求之後的第乙個處理階段，位於uri重寫之前，很少使用
server級別的重寫，處理位於server塊內和location之外的重寫指令
比如 index（位於server 塊內) 指令
比如 try_files(位於server塊內) 指令（在nginx裡面也是推薦使用try_files,等效於if-rewrite)
查詢location配置，該階段使用上一階段重寫後的uri,查詢對應的location
該階段可能會被執行多次
location級別的uri重寫，該階段執行location的基本重寫命令
如 rewrite trye_files
location重寫的最後乙個階段，檢查上一階段是否有uri重寫，如果有，跳轉到合適的階段
nginx 限制了最大重寫次數10次
訪問許可權控制的前一階段，該階段在許可權控制階段之前，一般也用於訪問控制，比如限制訪問頻率，鏈結數等
訪問許可權控制階段，比如基於ip黑白名單的許可權控制，基於使用者名稱密碼的許可權控制等；
訪問許可權控制的後一階段，該階段根據許可權控制階段的執行結果進行相應處理
ngx_http_try_files_phase（特殊，順序不固定)
try_files指令的處理階段，如果沒有配置try_files指令，則該階段被跳過
內容生成階段，該階段產生響應，併發送到客戶端
日誌記錄階段，該階段記錄訪問日誌
按照大類分：post_read階段，server_rewrite階段，find_config階段，rewrite階段，post_rewrite階段，preaccess階段，access階段，post_access階段，try_files階段，content階段，log階段
因為openresty裡面整合了很多模組，實際上就是在不同的處理階段註冊相應的函式，lua模組的加入讓nginx本身有了處理lua指令碼的能力
nginx對請求的處理模式是非同步非阻塞的，通過引數配置的優化(linux 核心引數優化），可以達到10萬左右的併發處理能力
openresty基於nginx，加上了很多第三方模組，主要是lua，能夠使得nginx在內部處理lua的指令碼，
lua雖然是指令碼語言，但是lua的效能很好，尤其是基於lua-jit的執行
這個是nginx+php-fpm的模型，當nginx接收到php請求，就會轉交給php-fpm
php-fpm接收到請求要進行一系列初始化工作，完了執行指令碼，之後釋放本次請求分配的資源，執行一些**操作
openresty接收到動態請求，用lua去處理，直接是在nginx內部，後續的一些動作沒有，而且lua-jit是非常高效的，因此openresty快是情理之中
由於lua和nginx結合的如此緊密，使得我們可以在nginx請求的各個階段靈活的處理
github位址
nginx.conf中可以使用的執行lua的指令
lua中可以使用的nginx api
WEB伺服器 與 應用伺服器
簡介 web伺服器 apache iis nginx 反向 伺服器 應用伺服器 tomcat weblogic jboss glassfish web伺服器則主要是讓客戶可以通過瀏覽器進行訪問，處理html檔案 應用伺服器處理業務邏輯 比如tomcat，支援jsp weblogic，支援ejb 兩者...
web伺服器與應用伺服器
web伺服器 web server 根據我們的定義，作為應用程式伺服器，它通過各種協議，可以包括http，把商業邏輯暴露給 expose 客戶端應用程式。web伺服器主要是處理向瀏覽器傳送html以供瀏覽，而應用程式伺服器提供訪問商業邏輯的途徑以供客戶端應用程式使用。應用程式使用此商業邏輯就象你呼叫...
Web應用伺服器優化方法
在對web 伺服器進行優化時要根據真實的web 應用系統的情況和特徵來採取有針對性地優化方案。首先根據不同的網路特性來看 在區域網中，降低m t u 最大傳輸單位 值對可以避免複製資料和求校驗，而通過優化select系統呼叫或在socket事件處理器中執行計算可以優化請求併發管理，利用http1 1...