qps、pv 、rt（響應時間）之間的關係
qps：單個程序每秒請求伺服器的成功次數
qps = req/sec = 請求數/秒
qps統計方式 [一般使用 http_load 進行統計]
qps = 總請求數 / ( 程序總數 * 請求時間 )
單台伺服器每天pv計算:
公式1：每天總pv = qps * 3600 * 6
公式2：每天總pv = qps * 3600 * 8
伺服器數量 = 每天總pv / 單台伺服器每天總pv
峰值qps和機器計算公式：
原理：每天80%的訪問集中在20%的時間裡，這20%時間叫做峰值時間
峰值時間每秒請求數(qps)：( 總pv數 * 80% ) / ( 每天秒數 * 20% )
峰值機器數量：峰值時間qps / 單台機器的qps
例子：問：每天300w pv 的在單台機器上，這台機器需要多少qps？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (qps)
問：如果一台機器的qps是58，需要幾台機器來支援？ 答：139 / 58 = 3
效能壓測的情況下，起初隨著使用者數的增加，qps會上公升，當到了一定的閥值之後，使用者數量增加qps並不會增加，或者增加不明顯，同時請求的響應時間卻大幅增加。這個閥值我們認為是最佳執行緒數。
為什麼要找最佳執行緒數
過多的執行緒只會造成，更多的記憶體開銷，更多的cpu開銷，但是對提公升qps確毫無幫助
找到最佳執行緒數後通過簡單的設定，可以讓web系統更加穩定，得到最高，最穩定的qps輸出
最佳執行緒數的獲取：
通過使用者慢慢遞增來進行效能壓測，觀察qps，響應時間
根據公式計算:伺服器端最佳執行緒數量=((執行緒等待時間+執行緒cpu時間)/執行緒cpu時間) * cpu數量
單使用者壓測，檢視cpu的消耗，然後直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳執行緒數量。
影響最佳執行緒數的主要因素：
ioio開銷較多的應用其cpu執行緒等待時間會比較長，所以執行緒數量可以開的多一些，相反則執行緒數量要少一些，其實有兩種極端，純io的應用，比如proxy，則執行緒數量可以開到非常大（實在太大了則需要考慮執行緒切換的開銷），這種應用基本上後端（比如這個proxy是**搜尋的）的qps能有多少，proxy就有多少。
cpu對於耗cpu的計算，這種情況一般來講只能開到cpu個數的執行緒數量。但是並不是說這種應用的qps就不高，往往這種應用的qps可以很高，因為耗cpu計算的應用，往往處理單次請求的時間會很短。
qps和執行緒數的關係
在最佳執行緒數量之前，qps和執行緒是互相遞增的關係，執行緒數量到了最佳執行緒之後，qps持平，不在上公升，甚至略有下降，同時響應時間持續上公升。
同乙個系統而言，最佳執行緒數越多，qps越高
響應時間優化
業務不停的迭代，加上打工人換了一波又一波，導致很多業務介面特別重，可讀性非常的差。最近專案在重構優化，部分介面平均響應時間在 1.5s 左右，對於使用者體驗來說，非常的不友好。本文旨在提出幾個介面優化的一些常用的辦法。1 優化的準則 一切的前提是業務價值需要。如果沒有足夠的價值，那麼可讀性才是第一，...
Eureka響應時間優化
1 心跳傳送時間間隔 eureka.client.leaserenewalintervalinseconds 2 心跳檢查間隔 eureka.server.evictionintervaltimerinms 3 readwrite 快取 同步到 readonly 快取中的 間隔時間 eureka.s...
通過Ethereal測量響應時間
我們在測試過程中有的時候響應時間可以通過客戶端效能測試工具獲得，但是有的時候不能，特別是非同步傳輸的系統，當系統請求發出後系統不是及時響應，而是通過後續的應用獲取資訊，這種情況下現有客戶端效能測試工具很難解決響應時間的衡量。因此在類似於此類測試過程中我們可以通過 ethereal 類似的協議分析工具...