# 并發能力
```
并發能力，是指 吞吐能力。
```
## 并發的2個問題針對解決：
1，是不是并發調度問題
2，是不是并發處理問題
## 壓力測試簡介：
[An Introduction to Load Testing | DigitalOcean](https://www.digitalocean.com/community/tutorials/an-introduction-to-load-testing)
*****
## 壓力測試工具
1， AB 壓力測試
```
sudo apt install apache2-utils
ab -n 5000 -c 500 https://yuan.liangdabiao.com/
```
參考文檔：[ab（http）與abs（https）壓測工具 - lsgxeva - 博客園 (cnblogs.com)](https://www.cnblogs.com/lsgxeva/p/12185925.html)
> Requests per second: 19.66 [#/sec] (mean)
//**吞吐率**，大家最關心的指標之一，相當于 LR 中的每秒事務數，后面括號中的 mean 表示這是一個平均值
**Time per request**: 5087.180 [ms] (mean)
//用戶平均請求等待時間，大家最關心的指標之二，相當于 LR 中的平均事務響應時間，后面括號中的 mean 表示這是一個平均值
**Time per request**: 50.872 [ms] (mean, across all concurrent requests)
//服務器平均請求處理時間，大家最關心的指標之三
*****
2，Pageload.io
非常不錯的可視化壓力測試工具，幫助進一步檢查，作為最后是否通過的檢測標準。
3，Jmeter
非常不錯的本地壓力測試，充分利用本地的強大計算和網絡能力，可以對比測試結果，方便排查性能問題原因。
*****
*****
*****
*****
*****
## 需要多少并發能力：
1，從GA，日志等檢查每天的流量，計算正常時間每分鐘訪問的流量和人次。
2，例如應付普通日常是 **250人/分鐘** ，那么為了活動做好準備，同時也要并發測試 **2500人/分鐘** ，。
3，同時也要為壓力測試做好準備，達到 **10000人/分鐘** ，能夠讓服務器不宕機。
4，要測試不同種類的頁面并發能力。重點：**首頁，結算頁**，商品頁，列表頁。
**注意：** 我們不是BAT,沒有那么高并發，流量都是要廣告買回來的。按實際情況準備好10倍的應付能力就可以了。
*****
*****
## 并發測試流程：
> 注意：Jmeter壓力測試工具測試，檢查情況,吞吐率是多少。然后再檢查性能監控的指標情況 【Tideways】，發現什么問題。然后迭代，進一步加大并發測試。
測試過程如下：
0，先把 外套都脫了 , (去掉緩存，靜態緩存等）
1， 1核2g服務器 測試
2， 加上 負載均衡 + 強大服務器 測試
3， 通過日常并發 250人/min, 再通過活動并發 2500人/min，再通過10000人/min 壓力測試。
4，每一個頁面都進行最高壓力測試，通過
*****
### 外套脫了
下架 redis對象緩存，下架頁面靜態緩存。
*****
### 1核2g服務器測試：
測試單核性能，找到標準吞吐率。
測試結果是：Requests per second = 1.7 ， waiting = 658ms
性能檢測結果：
發現問題： 1，sql太多。2，Unaccounted Wait 太久。
[What is "Unaccounted Wait"? :: Documentation (tideways.com)](https://support.tideways.com/documentation/reference/concepts/what-is-unaccounted-wait.html)
*****
### 那么，加服務器8核，加負載均衡：
*****
增加了一個8核8g的小型服務器，測試看看：
測試結果是：Requests per second = 12-15 ， waiting = 500ms ，并發處理能力增加8倍，對應著CPU的核數增加。
性能檢測結果：
發現問題： 1，sql太多。
*****
*****
*****
### 那么，加緩存：
希望：提升10倍，應付活動等并發：Requests per second =》 40/s - 160 /s，
開啟redis對象緩存+頁面靜態緩存：
Jmeter測試：
測試結果是：Requests per second = 80 ， waiting = 263ms
同時，通過10000人/min 的壓力測試。
性能檢測結果：
發現問題：都是幾ms，沒有問題，很好。
*****
### 最后用可視化 loader.io 測試 每一個頁面：
**checkout頁：**
> 備注: checkout url可以這樣測試 https://woocommerce.liang/index.php/checkout/?add-to-cart=191&variation_id=193
因為有流量轉化漏斗，這里只需要達到10分1的并發就可以。250人/min - 1000人/min , 看下圖測試結果，1000人/min 并發的結算功能 是沒有問題。
*****
**商品詳情頁：**
需要 2500 - 10000人/min,結果通過：
*****
**商品列表頁：**
需要 2500 - 10000人/min,結果通過：
*****
# 備注如下：
## "Unaccounted Wait" 很高 ？
當看到tideways顯示，"Unaccounted Wait" 很高，那么就可能要垂直升級服務器性能了
#### 1，先檢查php.ini配置
php-fpm.conf有兩個至關重要的參數：
一個是”**max\_children**”，另一個是”**request\_terminate\_timeout**”, 都檢查。參考：[php-fpm占用cpu和內存過高100% 解決辦法 - 上善若水-隨 - 博客園 (cnblogs.com)](https://www.cnblogs.com/boundless-sky/p/9223942.html)
*****
*****
#### 2，考慮升級服務器，升級多大服務器呢？ 【magic formula】
> 參考：[How to Estimate How Many Website Visitors Your Hosting Can Deal With (servebolt.com)](https://servebolt.com/articles/calculate-how-many-simultaneous-website-visitors/)
> The magic formula we use for our estimates, that captures the essence and provides us an approximate number of how many users you can have simultaneously on your site in Google Analytics is:
> **(number of CPU cores / Average Page Response Time in seconds) * 60 * User Click Frequency in seconds = Maximum simultaneous users**
（1），從GA看看，每分鐘的用戶有多少人在線。 例如，我們普通需求是平時 250人/min，要達到 2500人/min。
（2），利用公式計算： （ cpu核數 / 頁面響應時間） * 60 * 用戶點擊頻率 = 最大并發用戶數 。
用戶點擊頻率 = 平均1次/min （普通獨立站）
（ 4核 / 0.400s ) * 60 * 1 = 600 人/min
(32核 / 0.323s) * 60 * 2 = 11 880人/min
*****
簡化公式： 吞吐率 * 60 = 承受最大并發用戶數的能力
250人/min ， 那么就需要 吞吐率 達到 4/s Requests per second
2500人/min ， 那么就需要 吞吐率 達到 40/s Requests per second
10000人/min, 那么就需要 吞吐率 達到 160/s Requests per second
*****
*****
*****
*****
## 負載均衡問題 ？
RDS: 數據庫需要統一放在RDS.
Offload 資源：
放在Cloudflare CDN:
https://wordpress.org/plugins/cloudflare/
放在 [S3/OSS](https://kinsta.com/knowledgebase/wordpress-amazon-s3/)
https://cn.wordpress.org/plugins/amazon-s3-and-cloudfront/
不停重定向，解決方法：
```
在config.php 加上：
$_SERVER['HTTPS'] = 'on';
$_SERVER['SERVER_PORT'] = '443';
```
*****
## redis性能問題?
解：升級。
*****
## mysql 性能問題?
解：升級。
*****
## 活動已經過去，去掉添加的高配服務器
