促銷一開系統就掛——中小企業負擔得起的壓力測試怎麼做

平常好好的、一辦活動就當機

您的電商系統平常跑得好好的,客服、結帳都很順。但上個月辦了場週年慶,廣告投放一開、LINE 推播一發,系統就開始卡頓,最後乾脆死機兩小時。等工程師重啟好了,活動熱度也過了,客人也跑了。

這不是您一個人的經歷。<cite index="1-4,2-15">全球零售商在促銷期間系統當機的案例屢見不鮮,原因往往都是「沒有模擬真實流量高峰」</cite>。平常 50 個人在線上逛沒問題,促銷一來 500 人同時湧入,資料庫、API、圖片伺服器哪裡扛不住,您根本來不及反應。

好消息是:壓力測試並不需要幾十萬預算或專業團隊。只要搞清楚三件事——要測什麼、測多少人、哪裡會先倒——您就能在活動前把問題找出來,而且很多瓶頸其實很便宜就能解。

要測什麼:別只測首頁,要測「會員結帳」的完整路徑

很多老闆第一次做壓力測試,直覺就是「讓 1000 個機器人一直刷首頁」。結果測完綠燈通過,真正開賣時才發現:購物車頁面打不開、結帳按下去轉圈圈、訂單進不了資料庫。

<cite index="3-3,3-6">有效的負載測試必須模擬真實使用者的行為模式</cite>。對電商來說,完整的測試路徑應該包括:

• 瀏覽商品頁(有圖片、有庫存查詢)
• 加入購物車(會寫入 session 或資料庫)
• 進入結帳頁(要讀取會員資料、計算運費)
• 送出訂單(寫入訂單表、扣庫存、可能串金流)

每一步都會呼叫不同的系統元件。首頁可能有快取撐著,但結帳流程通常沒辦法快取,會直接打到資料庫——這才是最容易出事的地方。

測多少人才夠:從 Google Analytics 反推「同時在線人數」

很多老闆會問:「我要測 1000 人還是 10000 人?」答案是:先看您平常跟促銷時的真實數據。

<cite index="10-1,10-2">日流量(total users)跟同時在線人數(concurrent users)是兩回事</cite>。假設您的網站一天有 2000 人造訪,尖峰時段是晚上 8 點到 10 點(2 小時),平均每個人停留 20 分鐘。套用公式:

同時在線人數 = 日流量 / 尖峰時段 × (60 / 平均停留分鐘數)

以這個例子來說: 2000 / 2 × (60/20) = 2000 / 2 × 3 ≈ 3000 / 2 = 約 1500 人分散在 2 小時,每小時約 750 人,實際同時在線可能 30-50 人。

但促銷期間流量可能是平常的 3-5 倍。<cite index="10-14,10-15,10-16">流量分布不均勻,開賣瞬間可能出現 2-3 倍的微高峰</cite>。所以安全的測試目標應該是平常同時在線人數的 5-10 倍。

如果您平常同時在線 50 人,促銷時應該準備承受 250-500 人同時操作。這個數字聽起來不大,但如果系統沒優化,50 人就可能讓您的網站掛掉。

哪些瓶頸很便宜就能解:資料庫、圖片、沒有快取

壓力測試最大的價值,不是告訴您「系統會不會掛」,而是告訴您哪裡會先掛、為什麼掛。<cite index="10-20">系統承載能力取決於最弱的那一環</cite>。

從我們實際接手的案例來看,最常見的三個瓶頸:

1. 資料庫查詢沒有索引
每次結帳都要查會員資料、訂單紀錄,但資料表沒建索引(index),查詢時間從 0.01 秒變成 2 秒。50 個人同時結帳,資料庫就塞爆了。解法:請工程師檢查常用查詢欄位有沒有加索引,這通常只要改幾行 SQL。

2. 商品圖片沒有 CDN
首頁有 30 張商品圖,每張 500KB,每個使用者進來都要從您的主機下載 15MB。100 個人同時進站,頻寬瞬間吃滿,網站就卡了。解法:用 Cloudflare 或台灣本地 CDN(如中華電信、Hinet)把圖片快取到邊緣節點,每個月幾百塊台幣就能解決。

3. 沒有頁面快取
每次有人進首頁,系統都重新跑一次「撈取最新商品、計算折扣、組合 HTML」。其實這些內容 10 分鐘才更新一次,根本不用每次都算。解法:如果用 WordPress 裝個 WP Rocket,如果是客製系統請工程師加 Redis 或簡單的檔案快取。

這三個問題加起來,改善成本可能不到一萬塊,但能讓系統承載量提升 5-10 倍。

免費工具就能測:Apache JMeter、k6、Locust

壓力測試工具不需要花大錢。<cite index="18-1,18-2,18-3">對開發者主導的團隊來說,Grafana k6、Apache JMeter、Locust 都是成熟的開源選擇</cite>。

• Apache JMeter:最老牌、功能最完整,適合各種協定(HTTP、資料庫、FTP),免費開源。缺點是介面比較複雜,需要一點學習時間。
• Grafana k6:用 JavaScript 寫測試腳本,可以整合進 CI/CD 流程,對工程師很友善。有免費版跟付費雲端版。
• Locust:用 Python 寫,輕量、容易上手,適合不想搞太複雜的小團隊。

如果您的系統是外包或接手別人的,建議先請工程師用這些工具跑一次「100 人同時結帳」的測試,看看回應時間、錯誤率、哪個 API 最慢。光是這份報告,就能讓您知道系統準備好了沒。

下一步:在活動前做一次真實演練

壓力測試不是做一次就好。<cite index="5-18,5-19">最常見的錯誤是測太早——三週前測過了,之後又改了功能,結果活動當天出問題</cite>。

我們建議的節奏是:

1. 活動前兩週:做第一次壓力測試,找出明顯瓶頸(資料庫、圖片、API)
2. 活動前一週:改善完後再測一次,確認問題真的解決了
3. 活動前一天:做最後一次小規模測試,確認沒有新的改動影響效能

如果您的系統是自己接手、或外包做到一半還沒上線,現在正是做壓力測試的最佳時機。與其等到促銷當天才發現系統撐不住,不如提前知道哪裡有風險、需要補強什麼。

如果您想知道現有系統能不能安全上線、哪些地方需要優化,歡迎預約我們的免費程式碼健診。我們會幫您檢視系統架構、找出效能瓶頸,並給您一份具體的改善建議——讓您的下一次促銷不再因為當機而錯失商機。