# 虎年行大運 ~ Apache - MPM 工作模式調優

## 【前言】
偶爾開發上線後會遇到一種狀況是: 你的服務回應速度變得很慢，但查看了CPU使用率後，卻又發現被使用的狀況偏低，是什麼樣的事情正在發生才會產生這種詭異的狀況呢?

有一種可能便是 Apache 處理 Requests 的模式不適合。

也許你的服務很簡單，但 Apache 卻用了十分費力的方式，導致了 Connector 數量累積，直到服務反應越來越慢。

## 【什麼是 MPM?】
MPM 全名 Multi-Processing Module，意即多行程模式，有三種工作模式:
- Prefork
- Worker
- Event

三種模式各支援不同情境的需求，適當的切換，就算是最基本款的 GCP SaaS 方案，也能夠應付高流量的需求 (當然不包含到C10K的程度)。

## 【Prefork】
Apache MPM 最早期的模式，其做法是在 Apache 啟動後，預先建立數個子行程 (Child Process) 等著客戶端送來的 Request。

因為行程的建立與銷毀會耗費較多的資源與時間，因此預先建立的情況下，能夠讓後續準備接收的 Requests 的處理更快速。且因為是獨立的行程處理 Request 的關係，處理的效率也更好。

但超過已建立的子行程的狀況下，Apache 就必須要在繼續建立其他的子行程，並在回應 Requests 後將子行程的數量減少至原先預定的數量。

這些動作的時間將隨著接收的 Requests 量越大而越發地影響服務的穩定性。對於硬體設備的需求較高，卻無法因應高流量而顯得高效，也是 Prefork 只是基本模式而不是最佳模式的原因。

> Ngix 之所以成為顯學就是因為其面對 Reuqest 的部分是開出更多的 Thread 去處理而不是 Process 的方式。讓資源可以被快速分配利用，達成高效率的處理方式。

## 【Worker】
混合了 Process 和 Thread 的處理方式，同 Prefork 會預先建立許多 Process，且在個別 Process 中還會建立若干個 Thread，仿照 Ngix 利用 Threads 來處理 Requests 達成高效的處理方式。

缺點就是不同的 Threads 處理的 Requests 都歸在同一個 Process 底下，因此當這 Process 出問題的時候，便是底下所有的 Requests 都會受到影響。

## 【Event】
這是一個特殊模式，建立在 Worker 的基礎上，運作方式與 Worker 幾乎相同，主要是為了解決 Keep-alive 在長時間連結占用資源造成浪費的問題。

> Keep-alive 是保持主客端連線的機制，避免每次當客戶端提出 Request 後，還需要建立新連線再送 Request 過來，Keep-alive 是為了減少連線再建立的資源浪費而衍生的概念，有許多實現的作法。

切換到 Event 模式後，每一個 Process 中會有一個特別的 Thread 專門來管理、分配處理 Requests 的 Threads，這使得 Threads 不再被客戶端綁住，而能夠更有效率的分配資源在實際需要的 Requests。

## 【結語】
目前個人服務的公司，Apache 基本都是使用 Event 模式，畢竟在相同的硬體設備情況下，處理的效率比 Prefork 高出了 **50%**，尤其現在的服務面對不再是以往少流量的狀況，Event 模式的處理效率就更顯得高出 Prefork 許多。

上述這三個模式在切換的過程中，還有許多參數要去調整，Kai 這邊就做個紀錄而已~

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Apache`