景 #
這個事情也是最近做的，因為上線nginx被我換成了openresty，然后接入層服務也做了大改動，雖然我們app（internal office）的并發性不高，但還是壓力測試比較好，上線的時候穩定多了一點。
所以用jmeter來看看簡單的壓力測試，并記錄在這里。
這一次，我也找到了幾個可以按的接口：登錄界面，登錄后獲取用戶信息的界面，登錄后寫入數據的界面。
因為這些接口，在Postman中，我懶得手動輸入jmeter（那種表單，懶得一一獲取），唯一需要解決的就是，能不能在postman中導出請求，然后導入到jmeter中。
郵遞員請求導入 jmeter#郵遞員導出#
簡單來說，如果請求在 Postman 中不可用，您還可以使用數據包捕獲（Charles、Fiddler）將請求導出為 Charles 中的 curl 格式，然后將其導入 Postman。
郵遞員導入 jmeter 的方式也比較簡單，網上有人寫了一個開源庫來做這件事。
先出口：
你最終會得到一個 json 文件。
將json文件轉換為jmeter的jmx#
使用一個開源庫，也是用 Java 編寫的：
當我使用它時，因為我在 postman 中有一個請求有點問題，它會導致報告一個空指針，然后我自己調試它，它就解決了，所以你也可以拉我的存儲庫：
順便說一句，我還對原來的倉庫做了一個公關。
如何使用：
Copy$ git clone https://github.com/Loadium/postman2jmx.git
$ cd postman2jmx
$ mvn package
$ cd target/Postman2Jmx
$ java -jar Postman2Jmx.jar my_postman_collection.json my_jmx_file.jmx
通常，你最終會得到一個 my_jmx_file.jmx 文件，只需導入 jmeter。
jmeter config # 導入效果 #
打開這個jmx后，我做了一點修改，增加了查看結果的數量，修改了線程組的配置，大致如下：
我的項目仍然依賴于 cookie 機制，所以我在這里使用 cookie 管理器，它會自動將 set-cookie 存儲在線程的返回 cookie 區域，后續請求也會自動攜帶：
如果您不知道，可以單擊此頁面上的“幫助”以查看幫助文檔。
導入的效果還是相當不錯的：
設置線程組中的并發線程數#
一般來說，對于壓力測試，我們會關注某個接口的QPS或TPS，一般會添加一個監聽器，比如聚合報表，來檢查最終接口的吞吐量（TPS）
我們一般使用 jmeter 進行壓力測試的目的是，我需要對接口的極限是什么進行壓力測試，以及在當前的架構和環境中可以達到多少筆畫/秒。我得到了限制 TPS。
當然，我們也可能在一定程度上增加壓力，發現接口的TPS符合標準，所以我們不在乎，也不會繼續加壓，在增加的壓力下尋找TPS拐點。
但是，我之前一直有一個問題，那就是不知道如何設置jmeter中的并發線程數，經過檢查，我發現在性能測試領域，業界普遍稱這個值為VU（虛擬用戶）。
在制定測試計劃時，性能測試人員會先根據系統的大小和系統的峰值時間進行估算，總體來說還是有點復雜的。我在這里也看了一本書，全棧性能測試修煉書，其中第7章講到了如何計算。
我也在網上簡單查了一下，比如：
Copy通用公式
對絕大多數場景，我們用：
并發量=(用戶總量/統計時間)*影響因子（一般為3）來進行估算。
#用戶總量和統計時間使用2/8原則計算，即80%的用戶集中在20%的時間
#影響因子，一般為3，根據實際情況來
#通用公式使用了二八原則，計算的并發量即是峰值并發量。
例子
以乘坐地鐵為例子，每天乘坐人數為5萬人次，每天早高峰是7到9點，晚高峰是6到7點，根據2/8原則，80%的乘客會在高峰期間乘坐地鐵，則每秒到達地鐵檢票口的人數為50000*80%/（3小時*60*60s）=3.7，約4人/S，考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數肯定比這個要大，假定每個人需要3秒才能進站，那實際并發應為4人/s*3s=12，當然影響因子可以根據實際情況增大！
在地鐵示例中，對于并發用戶，應將其設置為 12
然后，文章中的另一個例子，它是根據PV計算的：
Copy根據PV計算
并發量=(日PV/統計時間)*影響因子（一般為3）
#日PV和統計時間使用2/8原則計算，即80%的用戶集中在20%的時間
#影響因子，一般為3，根據實際情況來
#PV公式使用了二八原則，計算的并發量即是峰值并發量。
例子
比如一個網站，每天的PV大概1000w，根據2/8原則，我們可以認為這1000w，pv的80%是在一天的9個小時內完成的（人的精力有限），那么TPS為：1000w*80%/(9*60*60)=246.92個/s,取經驗因子3，則并發量應為：246.92*3=740
所以，說到底并發用戶數不是很高，在一般的系統中，感覺jmeter中的并發線程數足以控制在500個以內，如果不行，在1000個以內就足夠了。如果超過1000，看看是否應該考慮使用多個jmeter實例進行分布式壓力測試，因為一般對于大公司這樣的大企業來說，壓力測試都是分布式壓力測試，壓力測試機集群從幾十個單元開始。
當然，如果你必須拼命增加單個 jmeter 實例（即 java 進程）中的線程數，你可以查看以下文章：
我們看看如何增加堆大小之類的，將線程數增加到 10,000 個線程，但無論如何我不推薦，畢竟機器一般只有幾個核心或幾十個核心，打開這么多線程會導致頻繁的線程切換。
線程組中其他屬性的設置#
以下圖為例：
300 個線程，但 Rapp-up 周期是 300s，這意味著我的 300 個線程將在 300s 內啟動，即 1s 將增加 1;如果設置為 1,300 個線程會在 1 秒內啟動，而且我覺得對電腦的影響比較大，所以還是溫和一點比較好。
循環計數我在這里設置為無限，那么，整個腳本就是一直在運行，當然不是，你可以看到，我在上圖中將持續時間設置為 600s，也就是說，腳本總共運行了 10 分鐘。
可以預測的是：
在前 300 秒中，它從 1 個線程逐漸增加到 300 個線程;在接下來的 300 秒內，300 個線程同時運行腳本，此時的壓力是穩定的 300 個虛擬用戶或并發產生的 300 個線程。
jmeter 運行 #
當我們進行嚴格的壓力測試時，我們通常不會在 GUI 中運行它，而是使用 CLI 方法。
例如，使用 CLI 在 Windows 下進行壓力測試
CopyF:\apache-jmeter-5.2.1\bin>jmeter -n -t Test.jmx -l result.jtl -j test.log
或者在 linux 下進行壓力測試：
Copy./jmeter -n -t Test.jmx -l result.jtl
長時間壓測
nohup ./jmeter -n -t Test.jmx -l result.jtl 2>&1 &
壓力測試時，輸出如下：
Copysummary=3801 in 00:00:40=94.5/s Avg: 417 Min: 13 Max: 3817 Err: 0 (0.00%)
表示現在是壓測開始后的第40s，3801是總共發出去的請求，94.5/s是這期間的tps，后面就是平均數、最小、最大、錯誤數
過了一會兒，會有一連串的這樣：
Copysummary + 2590 in 00:00:35=74.3/s Avg: 1076 Min: 97 Max: 9799 Err: 0 (0.00%) Active: 151 Started: 151 Finished: 0
summary=6391 in 00:01:15=85.1/s Avg: 684 Min: 13 Max: 9799 Err: 0 (0.00%)
這
+ 行表示增量，距離上一行結束已經過去了 35 秒，這 35 秒內生成了 2590 個請求，該時間段的 TPS 為 74.3
“=”的行是腳本開頭到現在為止的總指標，比如請求數6391，也就是40秒的請求數3801+增量2590
順便說一句，這次上線之前，為了測試穩定性，我按了18個小時：
另外，后面的活躍線程數，我用了200個并發18小時，第二天，我發現系統還是挺穩定的。
全棧(Full-Stack)是指一種解決問題域全局性技術的能力模型。
很多現代項目開發，需要掌握多種技術，以減少溝通成本、解決人手不夠資源緊張、問題閉環的問題。全棧對業務的價值很大，如對于整個業務的統籌、技術方案的判斷選型、問題的定位解決等，全棧技術能力有重要影響。另外對于各種人才配套不是很齊全的創業公司，全棧能解決各種問題，獨擋多面，節省成本，能在早期促進業務快速發展。
技術能力的發展有橫向和縱向兩種，橫向像瑞士軍刀，無所不能。而縱向像干將莫邪，技藝高超。而全棧是技術能力橫向和縱向兩個方向相互融合的結果。人的精力是有限的，不可能精通所有的技術領域，但是可以廣泛掌握整個問題域相關技術棧，再深入掌握1個或多個領域技術，成為相關領域的專家。
全棧的定義
(圖片摘自《程序員技能圖譜》)