tps和并發用戶數的關系?QPS Queries Per Second 是每秒查詢率 ,是一台服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間内所處理流量多少的衡量标準, 即每秒的響應請求數，也即是最大吞吐能力，今天小編就來說說關于tps和并發用戶數的關系?下面更多詳細答案一起來看看吧!

tps和并發用戶數的關系

QPS Queries Per Second 是每秒查詢率 ,是一台服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間内所處理流量多少的衡量标準, 即每秒的響應請求數，也即是最大吞吐能力。

TPS TransactIOns Per Second 也就是事務數/秒。一個事務是指一個客戶機向服務器發送請求然後服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數，

QPS和TPS區别

個人理解如下：

1、Tps即每秒處理事務數，包括了

1）用戶請求服務器 2）服務器自己的内部處理 3）服務器返回給用戶

這三個過程，每秒能夠完成N個這三個過程，Tps也就是N；

2、Qps基本類似于Tps，但是不同的是，對于一個頁面的一次訪問，形成一個Tps；但一次頁面請求，可能産生多次對服務器的請求，服務器對這些請求，就可計入“Qps”之中。

例子

例如：訪問一個頁面會請求服務器3次，一次放，産生一個“T”，産生3個“Q”

例如：一個大胃王一秒能吃10個包子，一個女孩子0.1秒能吃1個包子，那麼他們是不是一樣的呢？答案是否定的，因為這個女孩子不可能在一秒鐘吃下10個包子，她可能要吃很久。這個時候這個大胃王就相當于TPS，而這個女孩子則是QPS。雖然很相似，但其實是不同的。

并發數（并發度）：指系統同時能處理的請求數量，同樣反應了系統的負載能力。這個數值可以分析機器1s内的訪問日志數量來得到

吐吞量：吞吐量是指系統在單位時間内處理請求的數量，TPS、QPS都是吞吐量的常用量化指标

系統吞吐量要素

一個系統的吞吐量（承壓能力）與request（請求）對cpu的消耗，外部接口，IO等等緊密關聯。

單個request 對cpu消耗越高，外部系統接口，IO影響速度越慢，系統吞吐能力越低，反之越高。

重要參數

QPS(TPS),并發數，響應時間

1. QPS(TPS):每秒鐘request/事務 數量
2. 并發數：系統同時處理的request/事務數
3. 響應時間：一般取平均響應時間

關系

QPS(TPS)=并發數/平均響應時間

一個系統吞吐量通常有QPS(TPS),并發數兩個因素決定，每套系統這個兩個值都有一個相對極限值，在應用場景訪問壓力下，隻要某一項達到系統最高值，系統吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換，内存等等其他消耗導緻系統性能下降。

PV（Page View）：頁面訪問量，即頁面浏覽量或點擊量，用戶每次刷新即被計算一次。可以統計服務一天的訪問日志得到。

UV（Unique Visitor）：獨立訪客，統計1天内訪問某站點的用戶數。可以統計服務一天的訪問日志并根據用戶的唯一标識去重得到。 響應時間（RT）：響應時間是指系統對請求作出響應的時間，一般取平均響應時間。可以通過Nginx、Apache之類的Web Server得到。

DAU(Daily Active User)，日活躍用戶數量。常用于反映網站、互聯網應用或網絡遊戲的運營情況。DAU通常統計一日（統計日）之内，登錄或使用了某個産品的用戶數（去除重複登錄的用戶），與UV概念相似

MAU(Month Active User)：月活躍用戶數量，指網站、app等去重後的月活躍用戶數量

我們在做系統設計的時候就需要考慮CPU運算，IO，外部系統響應因素造成的影響以及對系統性能的初步預估。

而通常情況下，我們面對需求，我們評估出來的出來QPS，并發數之外，還有另外一個維度：日pv。

通過觀察系統的訪問日志發現，在用戶量很大的情況下，各個時間周期内的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。隻要能拿到日流量圖和QPS我們就可以推算日流量。

通常的技術方法：

1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）

2. 通過壓力測試或者經驗預估，得出最高TPS，然後跟進1的關系，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的TPS和PV關系比例也不一樣。

軟件做性能測試時需要關注哪些性能呢

首先，開發軟件的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關注哪些性能。

對于用戶來說，當點擊一個按鈕、鍊接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來為止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印 象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟件時，我們就需要 考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以将先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢 索，這時用戶并不知道我們後台在做什麼。

用戶關注的是用戶操作的相應時間。

其次，我們站在管理員的角度考慮需要關注的性能點。

1、 響應時間2、 服務器資源使用情況是否合理3、 應用服務器和數據庫資源使用是否合理4、 系統能否實現擴展5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少6、 系統性能可能存在的瓶頸在哪裡7、 更換那些設備可以提高性能8、 系統能否支持7×24小時的業務訪問

再次，站在開發（設計）人員角度去考慮。

1、 架構設計是否合理2、 數據庫設計是否合理3、 代碼是否存在性能方面的問題4、 系統中是否有不合理的内存使用方式5、 系統中是否存在不合理的線程同步方式6、 系統中是否存在不合理的資源競争

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!