http 、http-socket、socket 的區別

• http 和 http-socket 選項是完全不同的。第一個生成一個額外的進程，轉發請求到一系列的worker (將它想象為一種形式的盾牌，與apache或者nginx同級)，而第二個設置worker為原生使用http協議。
• socket 模式：接收的是uwsgi 協議的數據包，前台需配合nginx 做負載均衡轉發過來
• http-socket 模式： 接收的是http 協議的數據包，前台可配合nginx 轉發
• http 模式： 額外啓動一個http 進程（類似nginx）轉發 uwsgi 協議的數據包到worker,http 模式也可只當成nginx 使用

• 當使用 http 模式啓動時，worker 進程會隨機監聽一個端口， 當curl 測試返回curl: (52) Empty reply from server， 通常可能是iptables 防火牆的原因，導致請求無法到達workerj進程；

  uwsgi 加載app 失敗，Internel Error

  因為wsgi 的app 加載的時候依賴中間件，當中間件not ready 時，app 加載失敗， uwsgi 仍然運行中，但部分或全部worker 不能訪問， 解決辦法；

  • 增加參數 lazy-apps、need-app 參數，當有一個worker 加載失敗時，會kill all workers, 整個uwsgi 退出
  • 業務應用try catch , 碰到異常，直接os._exit(1), master 會主動拉起；
  • lazy-apps/lazy比較，lazy已經不建議使用

編譯的uwsgi 打包到新

環境，無法找到python 解釋器；

• 問題

  Could not find platform independent libraries <prefix>
  Could not find platform dependent libraries <exec_prefix>
  Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
  Fatal Python error: initfsencoding: Unable to get the locale encoding
  ModuleNotFoundError: No module named 'encodings'

• 2種解決辦法：

  1. python 安裝到，編譯uwsgi環境時python的路徑
  2. 指定PYTHONHOME 環境變量，export PYTHONHOME=python 安裝路徑， PYTHONHOME 下一定必須有 bin/ 、lib/

一定要啓動master manager, 來管理子進程worker, --master

如何使用keep-alive

1. 使用http 代理模式， keep-alive = 100(int, default 4), http-auto-chunked = true; add-header = Connection: Keep-Alive
2. 如果使用Http11-socket 模式，默認開啓keep-alive, 但timeout=4, 且不能修改；

=============
參考鏈接： https://uwsgi-docs-zh.readthe...

[uwsgi]
master = true
callable = app
; socket = 0.0.0.0:8082
; http = 0.0.0.0:8082
chdir = $(PATH)
wsgi-file = modules/webserver/app.py
; logto = /logs/%n.log
; processes = 8
threads = 1
lazy = true
log-maxsize = 102400000
; enable-threads = true
; pidfile = $(ST_DATA_PATH)/%n.pid

; pod 內查看 process 監控: uwsgitop 127.0.0.1:8300
stats = 0.0.0.0:8300
; 不記錄uwsgi的request日誌，只記錄錯誤日誌        
disable-logging = true
; 等同於 lazy = true. 在每個worker 裏都重新加載app，而不是僅在 master,可能會消耗更多的內存,但是能做到優雅重啓，服務不停機
lazy-apps = true
; 如果沒有app 加載，則退出
need-app = true
; 超時還沒有收到響應，客户端直接端口連接，但是服務器還在計算
; http-timeout = 2
; 等同於 http-timeout
; socket-timeout = 2
; 服務器超過 3s 後就直接不計算了
harakiri = 2
; 當一個請求是“harakiri”殺死的,會記錄信息到uwsgi日誌裏
harakiri-verbose = true

; 多線程的話，uwsgi會自動開啓 thunder-lock，但是多進程的話需要手動開啓。 
; 解決驚羣問題：多個進程或者線程在等待同一個事件，當事件發生時，所有線程和進程都會被內核喚醒。
; 喚醒後通常只有一個進程獲得了該事件並進行處理，其他進程發現獲取事件失敗後又繼續進入了等待狀態。
; 監聽同一個事件的進程數越多，爭用 CPU 的情況越嚴重（儘管實際上只有一個進程能成功獲得事件並進行處理），造成了嚴重的上下文切換成本。實驗發現，能夠將請求平均分配到多個worker
thunder-lock = true

; spare2: 適用於更快增長worker數，並且較慢降低 worker 數
cheaper-algo = spare2
; 啓用cheaper模式, 代表最少保持 的worker 數量, 要小於 processes
cheaper = 4
; 初次啓動時的數量
cheaper-initial = 8
; 每次需要增加的worker數
cheaper-step = 2
; 調整週期，單位：秒
idle = 30
; 上限盡量高點，以應對意料之外的高併發
processes = 25
# 當worker 進程常駐物理內存超過2048MB 時，進行重啓， evil-reload-on-rss 是暴力重啓，不等待當前請求處理完；
reload-on-rss = 2048
# uwsgitop 能顯示內存情況
memory-report = true