1 QPS(Queries Per Second)
每秒查詢率，一台伺服器每秒能夠響應的查詢次數。
一個特定的查詢伺服器在規定時間内所處理流量多少的衡量标準，即每秒的響應請求數，即最大吞吐能力。
2 TPS(Transactions Per Second)
事務數/秒。
一個事務指一個用戶端向伺服器發送請求，然後伺服器做出反應的過程。客戶機在發送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數。
辨明QPS和TPS
TPS即每秒處理事務數，包括了
- 使用者請求伺服器
- 伺服器自己的内部處理
- 伺服器傳回給使用者
- 這三個過程，每秒能夠完成N個這三個過程，TPS 就是N；
對于一個頁面的一次通路，形成一個TPS。但一次頁面請求，可能産生多次對伺服器的請求，伺服器對這些請求，就可計入“QPS”。
例如：通路一個頁面會請求伺服器3次，一次通路産生一個“T”，3個“Q”。
并發數
并發數（并發度）：指系統同時能處理的請求數量，同樣反應了系統的負載能力。這個數值可以分析機器1s内的通路日志數量來得到
吐吞量
吞吐量是指系統在機關時間内處理請求的數量，TPS、QPS都是吞吐量的常用量化名額。
系統吞吐量要素
一個系統的吞吐量（承壓能力）與request（請求）對cpu的消耗，外部接口，IO等等緊密關聯。
單個request 對cpu消耗越高，外部系統接口，IO影響速度越慢，系統吞吐能力越低，反之越高。
重要參數
QPS(TPS),并發數，響應時間
QPS(TPS)：每秒鐘request/事務 數量
并發數：系統同時處理的request/事務數
響應時間：一般取平均響應時間
關系
QPS(TPS)=并發數/平均響應時間
一個系統吞吐量通常有QPS(TPS),并發數兩個因素決定，每套系統這個兩個值都有一個相對極限值，在應用場景通路壓力下，隻要某一項達到系統最高值，系統吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換，記憶體等等其他消耗導緻系統性能下降。
PV
PV（Page View）：頁面通路量，即頁面浏覽量或點選量，使用者每次重新整理即被計算一次。可以統計服務一天的通路日志得到。
UV
UV（Unique Visitor）：獨立訪客，統計1天内通路某站點的使用者數。可以統計服務一天的通路日志并根據使用者的唯一辨別去重得到。響應時間（RT）：響應時間是指系統對請求作出響應的時間，一般取平均響應時間。可以通過Nginx、Apache之類的Web Server得到。
DAU
DAU(Daily Active User)，日活躍使用者數量。常用于反映網站、網際網路應用或網絡遊戲的營運情況。DAU通常統計一日（統計日）之内，登入或使用了某個産品的使用者數（去除重複登入的使用者），與UV概念相似
MAU
MAU(Month Active User)：月活躍使用者數量，指網站、app等去重後的月活躍使用者數量
系統吞吐量評估
我們在做系統設計的時候就需要考慮CPU運算，IO，外部系統響應因素造成的影響以及對系統性能的初步預估。
而通常情況下，我們面對需求，我們評估出來的出來QPS，并發數之外，還有另外一個次元：日pv。
通過觀察系統的通路日志發現，在使用者量很大的情況下，各個時間周期内的同一時間段的通路流量幾乎一樣。比如工作日的每天早上。隻要能拿到日流量圖和QPS我們就可以推算日流量。
通常的技術方法：
1、找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）
2、通過壓力測試或者經驗預估，得出最高TPS，然後跟進1的關系，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的TPS和PV關系比例也不一樣。
11、軟體性能測試的基本概念和計算公式
軟體做性能測試時需要關注哪些性能呢？
首先，開發軟體的目的是為了讓使用者使用，我們先站在使用者的角度分析一下，使用者需要關注哪些性能。
對于使用者來說，當點選一個按鈕、連結或發出一條指令開始，到系統把結果已使用者感覺的形式展現出來為止，這個過程所消耗的時間是使用者對這個軟體性能的直覺印 象。也就是我們所說的響應時間，當相應時間較小時，使用者體驗是很好的，當然使用者體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟體時，我們就需要 考慮到如何更好地結合這兩部分達到使用者最佳的體驗。如：使用者在大資料量查詢時，我們可以将先提取出來的資料展示給使用者，在使用者看的過程中繼續進行資料檢 索，這時使用者并不知道我們背景在做什麼。
使用者關注的是使用者操作的相應時間。
其次，我們站在管理者的角度考慮需要關注的性能點。
響應時間
2、 伺服器資源使用情況是否合理
3、 應用伺服器和資料庫資源使用是否合理
4、 系統能否實作擴充
5、 系統最多支援多少使用者通路、系統最大業務處理量是多少
系統性能可能存在的瓶頸在哪裡
7、 更換那些裝置可以提高性能
8、 系統能否支援7×24小時的業務通路
再次，站在開發（設計）人員角度去考慮。
架構設計是否合理
2、 資料庫設計是否合理
3、 代碼是否存在性能方面的問題
4、 系統中是否有不合理的記憶體使用方式
系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競争
參考
![Apache配置SSLApache配置SSL[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)