如果對壓力測試不熟悉的朋友，可以參考筆者先前分享的文章：「Apache Bench — 壓力測試好夥伴」

大綱
一、了解目前 Server 資源利用率
二、調整 php-fpm 參數
三、調整 nginx 參數增加併發數量

一、了解目前 Server 資源利用率

進入 Server 後，你可以用 top 這個指令來觀察 Server 的各項參數；它所呈現參數是動態的，非常易於理解與判斷。

接下來你可以執行一段 Apache Bench 的指令（建議是 POST），來測試看看他怎麼爆掉的：

ab -n 10000 -c 100 -p post.txt -T application/json -H ‘Authorization: Token your_token’ https://your_test_ip/

上面的指令執行後，可以得到類似下面的報表：

在上面報表中可以看到居然有 50% 的 request fail，可是用 top觀察 Server 的資源時，發現無論是 CPU 、記憶體距離極限還有一段距離，且 idle 都還有剩：

所以下面我教大家調整哪些 php-fpm & nginx 的設定，盡量讓這台 Server 發揮出他的極限。

備註 1：通常 POST 對資源的消耗遠超 GET，如果 API 會修改資料庫內容、進行複雜計算就會消耗更多資源，這些都是要考量進去的。

備註 2：我們的目標是追求承受最大流量，而不是努力把 CPU 和 MEM 耗盡；經實驗，有時把他們耗盡反而會有更多的 request fail，這部分有興趣的讀者可以自己實驗看看。

二、調整 php-fpm 參數

STEP 1：先進入 php-fpm 的 conf 設定檔

sudo vi /etc/php/7.4/fpm/pool.d/www.conf

然後認識以下參數各自有什麼作用：

• pm：預設為「dynamic」，如果設定為「static」下面的參數只有「pm.max_children」會生效。
• pm.max_children：設置子進程最大數值，子進程數量太少會影響處理連線的速度，太多可能會導致資源耗盡。
• pm.start_servers：php-fpm 啟動起始進程數，數值需小於 pm.max_children。

建議為：(pm.max_spare_servers — pm.min_spare_servers)/2

• pm.min_spare_servers：php-fpm 的最小空閒進程數。
• pm.max_spare_servers：php-fpm 的最大空閒進程數。
• pm.max_requests：當子進程的 request 數量到達後關閉，再開一個新的。

下面提供的參數僅為範例，請依照 Server 實際狀況調整，並且用 top 這個指令觀察資源消耗狀態（主要看 CPU、MEM 使用率）。

pm = dynamic
pm.max_children = 200
pm.start_servers = 150
pm.min_spare_servers = 100
pm.max_spare_servers = 200
pm.max_requests = 1000

STEP 2：完成後後重啟 php fpm

執行下面指令才會生效喔～

service php7.4-fpm restart

如果剛剛的參數設定上有問題或是錯誤，上面會有錯誤提示，跟著提示操作就好了：

三、調整 nginx 參數增加併發數量

調整完 php-fpm 的參數後，Server 相較之前可以承受更大的流量；但如隨著系統使用者的成長，你很快會遇到下一個瓶頸，在決定花錢升級 Server 硬體水平前，可以先嘗試調整 nginx 的參數，看看是否能在支撐一段時間ＸＤ

STEP 1：確認 Server 有多少個 CPU 核心

下面這段指令可以知道這台 Server 有多少個 CPU 核心（worker_processes）：

grep processor /proc/cpuinfo | wc -l

STEP 2：進入 nginx 的 conf 設定檔

接著進入nginx.conf，查看目前 nginx 默認使用多少 CPU 核心數。

vi /etc/nginx/nginx.conf

你可以將 worker_processes 調整成 CPU 核心數，或是用 auto 讓他自動偵測：

worker_processes auto;

如果系統會遇到高併發場景，可以設置 events 的參數如下：

• worker_connections：設定 worker 最大可承受連線數（最大值為 65535）。

連線的總數為 worker_processes * worker_connections。

• multi_accept：收到一個 request 後，盡可能多接收其他的 request。
• use epoll：利用很棒的演算法提升效能。

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

STEP 3：設定完記得要重啟 nginx

nginx -s reload

希望這篇文章能讓讀者初步了解在 php-fpm & nginx 的設定中，哪些參數可以讓 Server 承受更大的流量，如果讀者有使用其他妙招也歡迎分享喔～

文章大綱
一、撰寫 Auto Scaling 的 yaml 檔
  ➤ HorizontalPodAutoscaler（水平自動擴展）參數說明
  ➤ 建立「nodetest-k8s-auto.yaml」來做 Auto Scaling 測試
二、調整 Service、Deployment 參數並加入 yaml 檔
  ➤ 調整 Service 參數
  ➤ 調整 Deployment 參數
  ➤ 將 Service、Deployment 設定合併到 nodetest-k8s-auto.yaml 中
三、部署＆測試 pod 是否會依據流量的增加自動擴展
  ➤ 開啟流量監控、部署 K8s
  ➤ 取得 Deployment 的外部 ip，然後瘋狂存取來測試 Auto Scaling
  ➤ 瘋狂存取後後，確認 maxReplicas 設定是否生效
  ➤ 關閉存取後，確認 minReplicas 設定是否生效
  ➤ 測試完成後將建立的 K8s 服務刪除、關閉 minikube

如果讀者尚未在本機安裝 K8s 環境，可以先閱讀：「帶你將 Node.js Web App 給 Docker 化，並用 Kubernetes 部署的超簡單範例」來設定基礎環境喔！

一、撰寫 Auto Scaling 的 yaml 檔

你也可以直接去筆者的 github，直接將專案 Clone 到本機來做測試。

HorizontalPodAutoscaler（水平自動擴展）參數說明

• scaleTargetRef：填寫你想要針對哪個 ReplicaSet 或 Deployment 或 Replication Controller 來做 Scaling。
• minReplicas、maxReplicas：Pod 擴展範圍。
• targetCPUUtilizationPercentage：Auto Scaling 是根據 CPU 用量來做擴展，判定的依據為 Deployment resources 的 requests 設定值（如果沒填寫基本上就不會動 XD）。

建立「nodetest-k8s-auto.yaml」來做 Auto Scaling 測試

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: node-web-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: node-web-app
  minReplicas: 1
  maxReplicas: 5
  targetCPUUtilizationPercentage: 10

原始碼：nodetest-k8s-auto.yaml（GitHub Gist）

二、調整 Service、Deployment 參數並加入 yaml 檔

這裡的 Service、Deployment 都是從先前這篇文章改良過來的喔。

Docker image 可以 pull 筆者的範例，或是使用自己的都可以。

調整 Service 參數

• nodePort：這裡建議指定一個 port，如果沒有設定的話，最後對外 ip 的 port 為隨機產生。

調整 Deployment 參數

• resources 的 requests：如果 cpu 設定為 100m，而 targetCPUUtilizationPercentage 設定為 10；當 Pod 的 CPU 使用率為 1m（100m x 10%） 的時候就要進行 Auto Scaling。
• replicas：特別設定為 1 方便觀察，原則上他的值要跟 minReplicas 相同。

將 Service、Deployment 設定合併到 nodetest-k8s-auto.yaml 中

apiVersion: v1
kind: Service
metadata:
  name: node-app-service
spec:
  selector:
    app: node-web-app
  ports:
    - protocol: "TCP"
      port: 8080
      targetPort: 8080
      nodePort: 30390
  type: LoadBalancer

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-web-app
spec:
  selector:
    matchLabels:
      app: node-web-app
  replicas: 1
  template:
    metadata:
      labels:
        app: node-web-app
    spec:
      containers:
        - name: node-web-app
          image: babydragon9703111/node-web-app:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi

原始碼：nodetest-k8s-auto-extend.yaml（GitHub Gist）

三、部署＆測試 pod 是否會依據流量的增加自動擴展

開啟流量監控、部署 K8s

# 將 minikube 監控流量的 addons 打開
minikube addons enable metrics-server

# 部署剛剛建立的 nodetest-k8s-auto.yaml
kubectl apply -f nodetest-k8s-auto.yaml

# 查看 Auto Scaler 狀態
kubectl get hpa

一開始 TARGETS 會顯示 <unknown>，這是因為還在判斷流量，過一陣子就會顯示百分比了

取得 Deployment 的外部 ip，然後瘋狂存取來測試 Auto Scaling

# 取得 Deployment 的外部 ip（此時會看到 port 與設定的 nodePort 相同）
minikube service node-app-service --url

# 開始瘋狂存取剛剛輸出的 url 來確認 pod 是否會自動成長
while true
do curl <Deployment 的外部 ip>
done

瘋狂存取後後，確認 maxReplicas 設定是否生效

看 REPLICAS 這個欄位是否會依據流量的增加自動擴展到設定的 maxReplicas。

關閉存取後，確認 minReplicas 設定是否生效

將上面的存取 Deployment 外部 ip 的 while 迴圈關掉後，pod 會自動減少到設定的 minReplicas。

測試完成後將建立的 K8s 服務刪除、關閉 minikube

kubectl delete -f nodetest-k8s-auto.yaml
# 如果沒關閉的話，你會發現電腦燙燙的，CPU 居高不下
minikube delete

以上就是模擬 K8s Auto Scaling 的測試方法啦！希望讀者可以透過文章了解這個技術的應用～

大綱
一、文章目標
二、使用技術
  ➤ Redis
  ➤ Lua
三、程式架構
  ➤ 主程式：redisSecKill.js
  ➤ Lua腳本：secKill.lua
四、執行結果
五、補充

一、文章目標

1. 產生秒殺商品基礎資訊(商品名稱、庫存)
2. 模擬秒殺情境，確認是否會超賣
3. 確認有保存購買人資訊

二、使用技術

Redis

1. 如果完全沒有相關基礎，建議先參考這篇文章來安裝 Redis 以及他的 GUI 工具
2. 本篇文章使用 Redis 的 Hash、List type 來儲存資訊

Lua

1. 為了避免超賣，這裡採用 Lua 腳本
2. 在 Redis Server 執行 EVAL 指令時，在結果回傳前只會執行當下 Lua 腳本的邏輯，其他 Client 端的命令須等待直到 EVAL 執行完為止。

Lua 腳本的邏輯應盡量簡單以保證執行效率，否則會影響 Client 端的體驗

三、程式架構

主程式：redisSecKill.js

1. 先啟用 Redis Client 端（如未安裝相關套件，請在專案資料夾下輸入 yarn add ioredis）
2. 用 prepare 函式，以 Hash type 建立參加秒殺的產品庫存
3. 用 secKill 函式模擬使用者購買行為，緩存並執行 Lua 腳本

const fs = require('fs');
const Redis = require('ioredis');
const redis = new Redis({
    host: '127.0.0.1',
    port: 6379,
    password: ''
});

redis.on("error", function (error) {
    console.error(error);
});

async function prepare (item_name) {
    // 參加秒殺活動的商品庫存
    await redis.hmset(item_name, "Total", 100, "Booked", 0);
}

const secKillScript = fs.readFileSync('./secKill.lua');

async function secKill (item_name, user_name) {
    // 1. 緩存腳本取得 sha1 值
    const sha1 = await redis.script("load", secKillScript);
    // console.log(sha1);

    // 2. 透過 evalsha 執行腳本
    // redis Evalsha 命令基本語法如下
    // EVALSHA sha1 numkeys key [key ...] arg [arg ...] 
    redis.evalsha(sha1, 1, item_name, 1, "order_list", user_name);
}

async function main () {
    console.time('secKill')
    const item_name = "item_name"
    prepare(item_name)
    for (var i = 1; i < 10000; i++) {
        const user_name = "baobao" + i
        secKill(item_name, user_name)
    }
    console.timeEnd('secKill')
}
main()

原始碼：redisSecKill.js（GitHub Gist）

Lua 腳本：secKill.lua

在 Lua 腳本執行「取得商品庫存」➜「如果庫存足夠就-1」➜「儲存購買者資訊(List type)」

local n = tonumber(ARGV[1])
local order_name = ARGV[2]
if not n  or n == 0 then
    return 0       
end                
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
    return 0       
end                
if blocked + n <= total then
    redis.call("HINCRBY", KEYS[1], "Booked", n)
    redis.call("LPUSH", order_name,ARGV[3])                                   
    return n;   
end                
return 0

原始碼：secKill.lua（GitHub Gist）

四、執行結果

SETP 1：在專案資料夾下輸入 node redisSecKill.js 模擬秒殺

SETP 2：待執行完後，用 Redis GUI 程式確認商品沒有超賣

SETP 3：確認訂單都有對應的買家

五、補充

上面程式只是 MVP，現實狀況還有很多要討論的：

1. 哪些商品被列為秒殺，如何紀錄
2. 設定秒殺開始時間、結束時間
3. 存在 Redis 的資料怎麼存入關連式資料庫中

如果你對 Redis 感興趣，筆者這邊也整理了很多相關資源：
1. 一文讓你徹底瞭解 Redis(進階)，史上最全,不看後悔！！！【建議收藏】
2. 【总结】瞬时高并发（秒杀/活动）Redis 方案
3. redis 之 sorted sets 类型及操作
4. node.js 中对 redis 的安装和基本操作
5. Node.js 中实践 Redis Lua 脚本
6. 使用 Redis 搭建电商秒杀系统

筆者也是剛學習 Redis 的新人，如果描述有誤，或是有更好的解決方式，再麻煩大神們不吝賜教，感謝～