資料在網路上傳輸的時間分成兩部分，一部分是使用者請求的資料報到達伺服器的時間，另一部分是伺服器的回應資料經由網路傳送給客戶端的時間，這兩部分的時間稱為響應時間。響應時間的大小取決於頻寬和資料量的大小。
響應時間的其中大部分時間消耗在伺服器端，我們用吞吐率來衡量這部分時間，即每秒處理請求數。吞吐率影響因素有：伺服器的併發策略，i/o模型，i/o效能，伺服器硬體配置等，應用程式本身的邏輯複雜度等等。
瀏覽器端耗時的影響因素有：瀏覽器採用的併發策略，樣式渲染方式，指令碼直譯器的效能，頁面大小，頁面元件的數量，頁面快取情況，頁面元件網域名稱分布以及網域名稱dns解析等。
系統效能的瓶頸，會隨著系統的執行發生不斷的變化和遷移，比如由於站點使用者組成結構的多樣性和習慣的差異，導致在不同時段系統的瓶頸各不相同，又如站點在資料儲存量或者瀏覽量增長到不同級別的時候，系統瓶頸也會發生遷移。一旦找到真正影響系統效能的決定因素，就要對其進行調整和優化。
和共享頻寬的本質區別是什麼？如何在日常開發中，注意節省頻寬的問題？
在後續的文章中，將會做出**。了解網路原理，是乙個優秀架構師必須掌握的知識。
如果讓瀏覽器請求網頁的時候，減少網頁上的http請求，毫無疑問將會加快網頁的請求速度
使用指令碼語言編寫的程式檔案需要通過相應的指令碼直譯器進行解釋後生成中間**，然後依託在直譯器的執行環境中執行，所有生成中間**的這部分時間成了優化的乙個重要點。asp和jsp，均有內建的優化方案，比如直譯器對某個指令碼程式第一次解釋的時候，將中間**快取起來，以便下次直接使用。對於開源的指令碼語言，也有第三方元件來提供此類功能，比如php的apc元件等。
在實際生產中，動態內容快取是使用得比較多的技術，但不是所有的動態內容都適合網頁快取，快取帶來的效能提公升和有些動態資料實時互動的去修形成矛盾，這是乙個需要權衡的問題。
另一方面，成千上萬的快取檔案如何儲存？快取的命中率如何？快取的過期策略如何設計？在擁有多台web伺服器的分布式站點上應用動態內容快取需要考慮一些什麼問題呢？後續的文章將會做出**
動態內容快取是將資料和變現整體打包，有的適合不太適合業務場景。當我們的站點中某些動態內容的計算時間主要小號在一些特殊資料上，這些資料或是更新過於平凡，或是小號大量的i/o等待時間，比如對資料庫中某欄位頻繁更新和讀取，這是我們為了提高快取的靈活性和命中率，以及效能的要求，便開始考慮資料快取。
更加細粒度的資料快取避免了過期時大量相關網頁的整體更新，比如很多動態內容都包含了一段公用的資料，如果我們將整個頁面都快取，那麼加入這段資料頻繁更新導致這個整個網頁都要頻繁地重建快取，這對網頁的其他部分內容不太公平。
後面的文章將會對資料快取做出討論
大量的壓力測試對比資料蠱惑激進的開發者和運維工程師，只關注所謂的併發量冠軍，卻忽視了更加本質性的東西，甚至不了解測試資料的潛在前提。有人拿著資料說apache已經過時，我們必須停止表面現象的崇拜。
不同業務對伺服器的要求不盡相同，所以分離帶來的好處是顯而易見的。針對不同業務採用不同的併發策略，並且提供最合適的物理資源。
實際生產中，跨運營商的網路通訊是必須要考慮到的問題。如果通訊的兩段主機位於不同運營商的網際網路中，那麼資料必須流經兩個網際網路運營商的頂級交換節點和骨幹網路，在這個過程中還要經過更多次的儲存**，而且個網際網路頂級交換節點之間又存在出口頻寬的限制，如果網際網路之間資料通訊量比較大的話，那麼這個頂級交換節點，也就是出口，將會是瓶頸所在。
我們當然希望web站點的使用者和伺服器位於同乙個網際網路運營商的網路內，但如何實現，以後的文章將會做出**
當單臺伺服器所承受的壓力達到極限時，就需要更多伺服器來分擔工作，我們需要將流量和使用者請求轉移到更多伺服器上。
為此，我們需要通過不同的方法來實現web負載均衡，可能是簡單的http重定向，或者是基於dns的輪詢解析，或者通過反向**伺服器來實現負載均衡排程，還可以通過lvs來組建伺服器集群。通過這些具體的實現方法，我們更加關心的是，是否具備高可用性，還有影響規模拓展的制約因素。這些以後的文章將會做出**。
一些效能問題往往發生在表現不佳的資料訪問層面，這**於不合理的應用程式資料訪問元件設計，不合理的資料庫表結構設計以及對資料庫內部構造缺乏深入的了解，web伺服器和資料庫伺服器的資料通訊一般基於標準的tcp，即便他們位於同一臺物理主機上也是如此。其通訊連線的建立和釋放涉及代表一段核心緩衝區的檔案描述符的建立和銷毀，這需要不少的時間開銷，包括系統呼叫導致的核心態切換以及某些非同步阻塞i/o模型採用的檔案描述符佇列掃瞄機制。所以，頻繁的資料庫連線和釋放將導致資料訪問等待時間的加長，這段時間浪費得毫無意義。
使用資料庫的持久連線能有效解決這一難題，它包括不同程度上的持久化，本質的區別在於持久連線的應用範圍和生命週期，比如某個程序內部的全域性資料庫連線，共程序內所有計算任務共享，在這個程序終止後便被釋放；或者在某個動態內容的執行週期內，**層面的持久連線物件，在動態內容計算結束後便不復存在；還有跨程序的資料庫連線池，儲存多個持久連線**用程式重複使用。在這些採用資料庫持久連線的應用設計中，同時還要注意保證資料訪問的執行緒安全性。
另外，索引的合理使用對於以來資料庫訪問的web應用至關重要。以及還要考慮到針對不同儲存引擎的取捨。
資料庫模型的不良設計制約了橫向拓展和負載均衡，為此，我們將資料雜湊在多台主機，包括必要的冗餘資料，一次來合理地分散資料庫的密集訪問，資料庫擴充套件便成為我們考慮的方案
無論是**層面的擴充套件，還是架構層面的擴充套件，涉及的內容非常多，缺乏良好的可擴充套件性設計就像慢性自殺或者等待死亡，這比web漢典所能遇到的其他一切困難更讓人頭疼，一旦擴充套件無法進行，就是死路一條
可擴充套件性的目的在於適應負載的變化，從擴充套件的技術實現上來看，又包含了很多對區域性效能的思考，以及了解何時需要擴充套件，這離不開對於站點效能的把握
每一次技術的應用不當，都可能引入一定程度上的不可擴充套件。但實際生產中，不得不採用一些技術來構建web站點，這些技術可能就會引起不可擴充套件性。正確理解業務，做出取捨。
敬請期待後續。。。
web效能優化一
web效能優化對於任何大型專案都是必不可少的一環，那麼如何做好web端的效能優化，從哪些方面入手？這些問題猛地提出來會讓很多人有無從下手的感覺，那麼接下來，我結合一些前輩發表的文章並總結下個人的效能優化經驗，系統性的總結從哪些方面入手。首先提出乙個問題 瀏覽器的乙個請求從傳送到返回都經歷了什麼？乙個...
構建高效能web
一直想在web效能 可擴充套件性和可用性提公升領域有所深入，但由於這些經驗的沉澱，沒有比較集中的學習資料輔助，並且也一直沒有接觸過有大規模訪問需求的web專案，因此總是在這個領域門外徘徊。上星期讀到一本書，構建高效能web站點 感覺有點如獲至寶，完全可以稱為高效能web的入門寶典，雖然內容不夠深入，...
高效能服務優化
凡是努力過的人都有乙個共同點那就是懂得天賦的重要性，沒有天賦的人努力做的再好還不如人家隨便搞搞，雖說努力不一定會成功，但不努力真的很舒服，有時候不逼自己一下都不相信自己還能把辣麼簡單的事情搞砸，聊聊高效能服務優化這個重大課題就是為了證明一下自己的技術實力，其實知道的真的就這麼一點點。這是乙個嚴肅認真...