做一款網際網路產品，人們往往立馬就想到了海量使用者、海量資料、高併發、高效能。所以起初做架構設計時就把效能提到了乙個不得不做的地位。我個人是很反對這種「未雨綢繆」的方式的，因為對於乙個新應用來說獲取乙個網際網路使用者的成本並不小，而且「海量」不是短期內就會面臨的。所以請建議您最好先在基於投入產出比的考量下對快速實現or效能重要程度做出權衡後再做考慮，最好先實現應用再做優化，過早優化是萬惡之源這句話不是嚇唬小孩子的。當然，本文講的就是效能的考量，所以文章以下的講解是在你已經決定要重點考慮效能的基礎上。
效能無非就是為了通過縮短響應時間來獲得良好的使用者體驗，通常我們會說起2/5/10法則：使用者響應在2秒之內是很好的使用者體驗；使用者響應在2-5秒之間是一般的使用者體驗，使用者可以接受；但是使用者響應在5-10秒之間是很糟糕的使用者體驗，已經接近了使用者可接受的極限。所以我們為了減小使用者響應時間必須要分析出可能出現的效能瓶頸在**。
如圖我們可以很清晰的看出使用者在等待的過程中發生了什麼：
因為我們今天講的是構建高效能服務，所以3我們暫時忽略。所以響應時間 = 傳送時間 + 傳播時間 + 處理時間將要傳送的資料寫入程序的資料緩衝區；
呼叫系統api，這裡涉及到使用者態到核心態的轉化，將資料存入系統核心緩衝區；
資料從核心緩衝區進入網絡卡；
資料從網絡卡傳輸到網路線路；
所以傳送時間 = 資料量/頻寬，頻寬就是資料的傳送速度，就是通常我們所說的mb/s。那麼傳播時間又與什麼有關呢？很容易想到的就是傳輸距離和傳輸速度，傳輸距離就是我們現實中的從北京到上海的距離(鋪設網線的距離）。傳輸速度指的是訊號的傳輸速度，通常接近於光速，我們將其約等於2x10^8m/s。所以傳播時間 = 傳輸距離/傳輸速度。
現在我們得出了響應時間 = 資料量/頻寬 + 傳輸距離/傳輸速度 + 處理時間。到底是哪乙個步驟最大的影響了我們的使用者響應呢？我們舉個例子，假如客戶在蘭州，網路出口頻寬為4mb/s（實際運營商提供的4mb的網路上行頻寬遠遠低於4）；伺服器在北京，網路出口頻寬為100mb/s；蘭州距離北京約為2000km；傳送回應均為10kb(0.08mb)資料。
除去處理時間傳送時間+傳播時間才為0.04秒，彷彿可以看出影響我們服務效能的彷彿是在處理時間上。其實不然，這裡面哪一項都不能被完全忽略。比如剛才我們舉得就是個很極端的例子，客戶端上行頻寬不低，而且服務端只給這乙個使用者提供服務，所以兩端的傳送時間都很小；在傳輸上我們忽略了訊號的衰減，各級路由器的**，甚至不同運營商的互聯互通問題。但是這兩個問題通常不是我們程式開發者能解決的，這需要科學合理的idc的支援，而且這個成本是企業非常關注的。
所以我們還是把優化重點轉移到最後一項伺服器的處理時間，這裡才是考驗我們架構師，研發工程師，dba能力的地方。如何實現服務靈活的擴充套件，部署；如何設計服務的併發策略；選擇怎樣的i/o處理模型；如何降低業務邏輯複雜度；如何處理負載；如何優化資料庫......我們還有很長的路要走。
推薦書籍《構建高效能web站點》,感謝作者 郭欣給大家提供了這麼一本很優秀的國產書籍。
構建高效能服務的考量
做一款網際網路產品，人們往往立馬就想到了海量使用者 海量資料 高併發 高效能。所以起初做架構設計時就把效能提到了乙個不得不做的地位。我個人是很反對這種 未雨綢繆 的方式的，因為對於乙個新應用來說獲取乙個網際網路使用者的成本並不小，而且 海量 不是短期內就會面臨的。所以請建議您最好先在基於投入產出比的...
構建高效能web
一直想在web效能 可擴充套件性和可用性提公升領域有所深入，但由於這些經驗的沉澱，沒有比較集中的學習資料輔助，並且也一直沒有接觸過有大規模訪問需求的web專案，因此總是在這個領域門外徘徊。上星期讀到一本書，構建高效能web站點 感覺有點如獲至寶，完全可以稱為高效能web的入門寶典，雖然內容不夠深入，...
PHP構建高效能系統
首先，我們需要清楚在業務上有什麼要樣的效能需求 第二步，根據效能的要求去考慮系統的設計，第三步，系統的開發過程中去關注可能存在的區域性效能問題。沒有開發過效能敏感系統的團隊，容易犯的錯誤是，不去考慮系統將來有多少人使用，併發訪問有多高，需要存貯多少數量的資料？直接就開始做系統的開發，抱著等著出了效能...