一、吞吐量與響應時間
系統的吞吐量反映了一個系統的容量，可承受的負載，很多系統都以這樣一個指標來衡量系統的性能。而響應時間往往更容易忽視。我認為吞吐量更多是衡量一 個系統在特定壓力下的穩定性，而響應時間可以更好的形容系統性能。一個請求響應時間滿足不了需求，那系統再高的吞吐量是沒有意義的。比如普通的網站頁面， 如果客戶的一個請求都能在200ms以內響應，那是非常不錯，如果能在2秒內響應，那也還行，但如果都要在20秒響應，估計沒人使用。而對於局域網內的應 用，如營業廳收費操作，這種響應時間如果是2秒都會讓營業員有明顯的不爽。
二、忽視系統環境差異
我們是否經常出現線下性能測試非常好，線上性能很差問題，或者是A環境好，B環境性能差。這種情況大部份是系統環境的差異，如兩個環境硬件不一樣，配置參數不一樣，數據規模不一樣，緩存命中率不一樣等等。在做性能測試時需要深入分析正式環境的各種數據細節，然后在做性能測試時有針對性的去模擬。
三、性能測試無用論
性能測試是一個非常復雜的工作，也是最考驗人計算機功底的工作，性能測試並不僅是學習如 何使用loadrunner或jmeter之類的工具，更多是要分析用戶及業務場景，估算並驗證系統性能容量，找出性能瓶頸並解決。精通測試工具可以更好 的提高工作效率。之所以有些人會提出性能測試無用論，大部份因為他認為正式環境太復雜，無法有效模擬出正式環境的瓶頸。其實這也是性能測試的難點，如何在 不同的環境中模擬出性能瓶頸。如果是普通測試工程師，估計只會根據業務邏輯搭建性能測試環境，並給出測試結果。如果是高級測試工程師應該清楚系統架構、應 用邏輯、業務場景、數據分布、硬件性能等等，最后給出有意義的性能測試模擬場景和數據。
性能測試最容易忽視的是數據分布與緩存命中率。正式環境的數據分布可以通過線上數據抽樣，沒有正式數據只能根據業務評估。比如工作流應用中個人平均待辦工單是多少？電子商務應用中熱銷商品的評價記錄會有多少？這些數據分布對性能測試的結果有非常大的影響。
緩存命中率對性能測試結果的影響更恐怖，可能有10倍，甚至上萬倍都不為過。常用如CPU cache對內存的緩存，內存對硬盤的數據緩存，memcached對db數據的緩存，瀏覽器本地對遠程的緩存。我們做性能測試需要仔細分析正式的緩存命 中數據，然后模擬最差值、正常值、最好值去評測，最后分析出緩存命中率對真實性能的影響。
四、缺少性能量化
性能量化是指對系統功能或硬件的主要指標進行性能指標計算，比如一個查詢請求的所有開銷計算，包括網絡開銷，應用服務器開銷，數據庫服 務器開銷等等，或者是更細化的CPU開銷，內存開銷，IO開銷等。性能量化還包括系統所使用的硬件指標，包括CPU性能，內存容量及性能，硬盤帶寬及 IOPS，網絡帶寬及延時等等。沒有這些基礎數據是很難做性能量化，否則只能做簡單的表面性能測試，給出一些感性數據，准確的系統整體性能容量評估也無從 談起。沒有扎實的性能量化基礎數據，搞不清楚一個邏輯在各個環節開銷，那做性能優化只能是憑感覺或經驗走。
五、硬件成本
在IT人的眼里硬件的費用是很高的，軟件成本是很低的甚至可以忽略，因為硬件需要購買，基本上沒有免費的硬件，而軟件可以選擇開源免費的，或者自己開 發，甚至使用盜版。因此在遇到性能問題是程序員首先想到的優化軟件性能。但在這個人工成本上升，硬件成本下降，硬件性能或容量隨摩爾定率的發展的時代，我 們也應該重視硬件的優化方法。
如果是服務器網絡瓶頸，百兆接口升級到千兆，千兆升級到多口千兆甚至是萬兆，這種升級都可以快速解決性能問題。單塊SATA硬盤吞吐量不夠，可以選擇 換SAS 15K硬盤，吞吐量就提升1倍，如果還不夠可以選擇多塊硬盤做RAID，實現一個數量級內近線性的吞吐量提升，如果是硬盤IOPS低，可以選擇換SATA 的SSD硬盤，能提升10倍以上的IOPS，如果要求更高可以選擇換PCIe的SSD硬盤，可以提升100倍以上的IOPS。內存不足可以增加內存容量， 當前單根4G，8G容量的內存性價比都不錯。CPU升級一般比較麻煩，因為受到CPU架構的影響，且CPU的發展較快，成本較高，所以很少做，對於老的服 務器CPU不足一般會選擇直接淘汰，重新采購新的。
通過硬件升級可以快速解決系統性能問題，對於可預估的系統容量性價很好。但頂配或者新出來的硬件貴得離譜，最新的硬件往往也會存在一些未知的BUG， 所以硬件升級一般不會選擇1年內出來的全新架構的設備，而通常選擇2年以上比較成熟的硬件性價比會更好。但是硬件升級往往會有上限，頂配或者最高性能的硬 件往往性價比不好，所以在硬件升級解決問題后同時需要分析業務增長導致更多硬件成本的問題。選擇軟件優化還是硬件優化是一種技術成本平衡決策，有時軟件也 需要針對硬件做特定的優化。
六、緩存的威力
緩存是好東西，基本上90%的系統架構優化都是在圍繞着如何利用好緩存。緩存真是無處不在，硬件上看，有硬盤緩存，RAID卡緩存，存儲緩存，主 存，NUMA特性，CPU L3-L2-L1等等。軟件架構上看，有全局數據緩存，私有數據緩存，連接池，應用服務器緩存，WEB服務器緩存，CDN緩存，客戶端文件緩存，客戶端內 存緩存等等。基本上大型系統都會有很多級緩存，否則需要非常高的硬件投入才能解決問題。硬件緩存通常都比較智能，或者說99%的情況下我們不需要修改配 置，即使修改帶來的性能提升一般也不會太多，除非你的軟件有較明顯的缺陷，你對硬件和你的軟件特性已經了解得非常深入。 軟件緩存架構帶來性能的提高，往往也帶來了負面的問題，如架構復雜化，數據同步多，數據不實時，維護成本高，系統調試復雜等問題，所以對於軟件架構上任何 一個緩存架構，都需要深入分析是否有必要。我認為如果增加一層緩存架構，至少要有5倍以上的提高提升，否則就要分析成本了。 對於中小型系統，不建議有復雜的緩存架構，因為讓系統能更快速發展比提供更好的性能更有意義，雜的緩存架構往往需要投入更多的人力成本。
七、客戶第一
我不知道客戶第一是誰提出來的，但這個詞真不能從字面上去理解，否則就會讓我們走向歪路。首先，誰是我們的客戶，誰是我們的直接客戶，誰是我們的最終 客戶，付錢給我們的是否就是我們的客戶？客戶類型1與客戶類型2發生了利益沖突，我們該以誰為第一。重要的客戶與大部份客戶利益有沖突時如何處理。這些看 似與系統性能優化無關的話題，但往往左右我們系統設計的方方面面。我們做的工作有沒有為了個別客戶去優化他的界面流程或性能而讓大部份用戶認為系統更復雜 或更難使用。
八、過度優化
大家都清楚性能優化的重要性，因此我們很多經歷都是在做系統優化，也導致我們有時會犯過度優化的錯誤。有人說他性能優化提高了10倍，100 倍，1000倍，但我們有時並不需要這種做法，這種事情更多是自己在優化技能上的一個學習。我們在做優化時應該多問一些問題 ：你的優化讓系統有什么變化：
你的優化有沒有讓系統更復雜了，以后的維護成本高了一些？
你的優化是否對大部份業務場景有效，還是只是為了一小部份場景優化而讓其它主業務變慢或變復雜了？
你的優化對客戶體驗有感覺嗎？
你的優化方法可持續有效嗎，還是業務邏輯稍有變化就失效了？
......
我認為系統優化一定要有一個目標，而不是一味的提高性能，因為在性能優化的背后一定會帶來或多或少的系統復雜度。系統性能優化在滿足需求的情況下，需要開始衡量是否會讓系統架構擴展性更差，或系統穩定性變差，可維護性變差等問題。