在做效能測試的時候，傳統方式都是用併發虛擬使用者數來衡量系統的效能（站在客戶端視角），一般適用於一些網頁站點比如首頁、h5 的壓測；而 rps（requests per second）模式主要是為了方便直接衡量系統的吞吐能力-tps（transaction per second, 每秒事務數）而設計的（站在服務端視角），按照被壓測端需要達到tps等量設定相應的rps，應用場景主要是一些動態的介面api，比如登陸、提交訂單等等。
vu（虛擬使用者）和tps之間也有其邏輯關係。具體請看下方的說明。
處理能力：簡稱tps, 每秒事務數, 是衡量系統效能的乙個非常重要的指標。
已有系統：可選取高峰時刻，在一定時間內（如3-10分鐘），獲取系統總業務量，計算單位時間（秒）內完成的筆數，乘以2-5倍作為峰值的tps，例如峰值3分鐘內處理訂單18萬筆，平均tps是1000，峰值tps可以是2000-5000。
針對伺服器端的效能，以tps為主來衡量系統的效能，併發使用者數為輔來衡量系統的效能，如果必須要用併發使用者數來衡量的話，需要乙個前提，那就是交易在多長時間內完成，因為在系統負載不高的情況下，將思考時間(思考時間的值等於交易響應時間)加到串聯鏈路中，併發使用者數基本可以增加一倍，因此用併發使用者數來衡量系統的效能沒太大的意義。同樣的，如果系統間的吞吐能力差別很大，那麼同樣的併發下tps差距也會很大。
做效能測試需要一套標準化流程及測試策略。在做負載測試的時候，傳統方式一般都是按照梯度施壓的方式去加使用者數，避免在沒有預估的情況下，一次加幾萬個使用者，導致交易失敗率非常高，響應時間非常長，已經超過了使用者忍受範圍內；較為適合網際網路分布式架構的方式，也是阿里的最佳實踐是用tps模式（吞吐量模式）+設定起始和目標最大量級，然後根據系統表現靈活的手工實時調速，效率更高，服務端吞吐能力的衡量一步到位。
LoadRunner 虛擬使用者數和併發使用者數的聯絡
oa系統使用使用者是100個，這個就是系統使用者數。承受的壓力。因為伺服器 併發使用者 是同時執行乙個操作的使用者，或者是同時執行指令碼的使用者，這個併發在設定不同場景的時候併發的情況是不一樣的，在實際的測試 估算併發數的公示 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c ...
虛擬DOM的解讀
我們知道virtual dom的作用是為了避免直接操作dom，因為直接操作dom是一件很費效能的事情，但是虛擬dom最後要渲染成真實的dom，也是需要採用dom操作的，那效能優化，優化在 var element children 該節點的子節點 children item 1 children it...
vsftpd 的虛擬使用者
vsftpd 的虛擬使用者 一 開始配置 1 裝包 yum install y vsftpd db4 utils 2 建立乙個對映虛擬使用者的真實使用者，就是所以虛擬使用者是以這個身份去登陸的,系統並不需要讓這個使用者登陸，所以shell設定為 sbin nologin這樣比較安全一點 userad...