總的來說，系統的設計是否合理，比區域性**問題，對效能的影響更大。
例如，程式設計成頻繁讀寫磁碟中的資料，肯定比先把資料一次性載入到記憶體中再讀寫，在合適的時候再寫入更新到磁碟的設計，效能要差很多。
使用伺服器集群、多執行緒多程序的架構，肯定比使用單伺服器、單執行緒單程序的架構，效能要差。
服務端使用非同步通訊的設計，肯定比同步通訊要好。
通訊訊息的設計，訊息體的長度設計為變長，肯定要比設計成定長，效能更好。
使用資源池設計，肯定是比頻繁建立/銷毀資源要好。
對於頻繁隨機刪除的操作，選擇list比vector效能要好。
不同的系統，高效能的指標是不一樣的。
對於資料流處理系統，主要指每秒處理的流量（bps）、資源佔用率。
對於**，高效能包括響應時間、支援的併發數、吞吐量 等。
對於儲存系統，主要包括iops、頻寬。
資料流處理系統，主要注意要將資料盡量放在記憶體中處理，寫磁碟時採用帶快取的api，採用合理的資料結構和演算法、不要頻繁的建立/釋放資源（可以的話就一直持有開啟的資源）、等等。
對於**，可分為web前端優化、應用服務端優化、儲存優化。
web前端優化：瀏覽器優化、運用cdn、使用反向**等等。
服務端優化：快取、非同步、負載均衡/集群、**優化
快取是優化第一定律。它本質是乙個hash表，將資料以key-value方式儲存在記憶體的hash表中。 客戶端先從快取中查詢資料，如果沒有則去資料庫查詢，返回結果並更新到快取中。一般採用lru（最近最久未用演算法）更新快取中資料，有可能會出現資料不一致的情況，但如果業務要求不高那也可以接受。也可以採用主動通知更新快取資料，但這樣的
設計會帶來較大開銷。它適用於讀寫比很高、較少變化的資料，頻繁修改的資料並不適合放在快取。分布式快取架構分為2種，一是以jboss cache為代表的需要同步更新的快取，一是以memcached為代表的互不通訊快取。 jboss cache需同步更新，當集群規模較大時，更新代價驚人，所以一般用在較小規模的、企業應用系統中。 memcached不需互相通訊，所以理論上可無限擴充套件。
**優化：多執行緒/多程序，資源池，演算法資料結構 等等。 多執行緒中，採用無狀態物件、多使用區域性變數、併發訪問資源加鎖等等。
PHP構建高效能系統
首先，我們需要清楚在業務上有什麼要樣的效能需求 第二步，根據效能的要求去考慮系統的設計，第三步，系統的開發過程中去關注可能存在的區域性效能問題。沒有開發過效能敏感系統的團隊，容易犯的錯誤是，不去考慮系統將來有多少人使用，併發訪問有多高，需要存貯多少數量的資料？直接就開始做系統的開發，抱著等著出了效能...
構建Nginx Cache高效能快取系統
隨著nginx web伺服器得到越來越多的sa的青睞，nginx的cache功能已經具備squid所擁有的web快取加速功能 清除指定url快取的功能。而在效能上，nginx對多核cpu的利用，勝過squid不少。另外，在反向 負載均衡 健康檢查 後端伺服器故障轉移 rewrite重寫 易用性上，n...
高效能，高可用系統架構
本文是學習大型分布式 架構的技術總結。對架構乙個高效能，高可用，可伸縮，可擴充套件的分布式 進行了概要性描述，並給出乙個架構參考。一部分為讀書筆記，一部分是個人經驗總結。對大型分布式 架構有很好的參考價值。1 大型 的特點 2 大型 架構目標 3 大型 架構模式 4 高效能架構 以使用者為中心，提供...