參考：《thinking clearly about performance》
響應時間：執行乙個任務所耗費的時間
吞吐量：在指定的單位時間內執行任務的個數
（真實關係比較複雜）
> 如果每秒吞吐量是1000，平均響應時間不一定是0.001秒。因為可能是有1000個並行通道，每個通道執行乙個任務，響應時間是1秒。
> 如果響應時間是0.001秒，每秒吞吐量有可能100都達不到。因為請求可能來自不同的使用者，請求之間不是完美連續的，可能有資源競爭等各種原因。
所以兩者都得測量。
平均值相同的情況下：
> 如果各響應時間相差較大（方差大），可能會導致業務無法容忍那些大於平均值的時長。
> 但也有可能業務要求某些任務的響應時間極短，同時容許個別任務可以稍微花費較長時間。
首先確定具體期望達到的效能目標，確定這個目標是使用者真實了解並期望的。
> 用序列圖展示流程
> 使用專業的測量評估工具（profiler），找出時間花在哪部分，哪部分的耗時可以接受。根據 profiler 的結果，估算應該能達到的效能目標。
- 阿姆達爾定律
系統中對某一部件採用更快執行方式所能獲得的系統效能改進程度，取決於這種執行方式被使用的頻率，或所佔總執行時間的比例。
- 評估每項改進所需成本。評估可能會不準確，可能會有一些關鍵點未考慮到，可能破壞原有設計，引發其它部分的效能問題。
- 記錄改進的歷史。包括期望效果，實際結果等。
- 單個子程式在不同場景效能表現分布不均勻。對某些被大量呼叫的子程式進行改造不一定能獲得預期效果。可能單次呼叫耗時可以減少一半，但由於每次呼叫情況可能相差很大，這些呼叫的總體耗時並不一定能減少一半。
- 效率
* 關注業務最需要改進的地方。
* 在不犧牲業務功能的情況下，去掉冗餘的操作/呼叫。
* 改進程式周邊的環境（不合理的設計、硬體配置等）。（必要時減少系統工作量）
- 負載
（開發人員不能檢測出所有效能問題的原因之一）
* queuing delay
各硬體（cpu、記憶體、磁碟等）有各自的效能拐點。
* coherency delay
為保持一致性引發的延遲，包括各種鎖。（很難保證效能測試已驗證該類延遲不會影響最終服務。）
（吞吐量比較容易測得，準確測得響應時間比較困難。）
最好是測量真正需要的，而不是那些容易測量的替代資料。
之前的階段應該考慮到是否容易開展效能測試，新增收集效能相關資料的**。
C 一些基本概念
建構函式的作用是對物件本身做初始化工作，也就是給使用者提供初始化類中成員變數的一種方式。析構函式是釋放物件執行期間所申請的資源。函式的過載，過載構成的條件 函式的引數型別不同 引數個數不同，才能構成函式的過載 在乙個類中 注意，只有函式的返回型別不同是不能構成函式的過載。在函式過載時，要注意函式帶有...
linux OS一些基本概念
1.什麼是os？好簡單好x的問題，可是如果真的要自己用稍微官方稍微正規的語言或文本來回答，我真的能回答清楚嗎？好吧，我先來用自己的語言來回答。再去找點官方的定義。我自己的回答 os就是乙個可以管理並且相對合理分配計算機資源的軟體。官方回答 作業系統 英語 operating system，簡稱os ...
Thread一些基本概念
1 實現執行緒的三種方式 extends thread implements runnable implements callable new futuretask callable new thread futuretask 2 執行緒讓步yield 讓執行緒由執行狀態變為就緒狀態，不會釋放鎖 3...