構建高性能Web站點

內容概要

　　 本書圍繞如何構建高性能Web站點，從多個方面、多個角度進行了全面的闡述，涵蓋了Web站點性能優(yōu)化的幾乎所有內容，包括數據的網絡傳輸、服務器并發(fā)處理能力、動態(tài)網頁緩存、動態(tài)網頁靜態(tài)化、應用層數據緩存、分布式緩存、Web服務器緩存、反向代理緩存、腳本解釋速度、頁面組件分離、瀏覽器本地緩存、瀏覽器并發(fā)請求、文件的分發(fā)、數據庫I/O優(yōu)化、數據庫訪問、數據庫分布式設計、負載均衡、分布式文件系統(tǒng)、性能監(jiān)控等。在這些內容中充分抓住本質并結合實踐，通過通俗易懂的文字和生動有趣的配圖，讓讀者充分并深入理解高性能架構的真相。同時，本書充分應用跨學科知識和科學分析方法，通過寬泛的視野和獨特的角度，將本書的內容展現得更加透徹和富有趣味。

作者簡介

郭欣，曾在騰訊網基礎平臺研發(fā)團隊，負責諸多Web應用的開發(fā)和技術管理，并致力于性能研究和實踐推廣。在加入騰訊之前，獲得國家系統(tǒng)分析師職稱，目前在工作之余從事獨立研究，其中包括高性能Web架構和Web敏捷開發(fā)框架，并且積極投身開源事業(yè)，同時在為Smart Developer系列進

書籍目錄

第1章　緒論　　1.1　等待的真相　1.2　瓶頸在哪里　1.3　增加帶寬　1.4　減少網頁中的HTTP請求　1.5　加快服務器腳本計算速度　1.6　使用動態(tài)內容緩存　1.7　使用數據緩存　1.8　將動態(tài)內容靜態(tài)化　1.9　更換Web服務器軟件　1.10　頁面組件分離　1.11　合理部署服務器　1.12　使用負載均衡　1.13　優(yōu)化數據庫　1.14　考慮可擴展性　1.15　減少視覺等待第2章　數據的網絡傳輸　2.1　分層網絡模型　2.2　帶寬　2.3　響應時間　2.4　互聯互通第3章　服務器并發(fā)處理能力　3.1　吞吐率　3.2　CPU并發(fā)計算　3.3　系統(tǒng)調用　3.4　內存分配　3.5　持久連接　3.6　I/O模型　3.7　服務器并發(fā)策略第4章　動態(tài)內容緩存　　4.1　重復的開銷　4.2　緩存與速度　4.3　頁面緩存　4.4　局部無緩存　4.5　靜態(tài)化內容第5章　動態(tài)腳本加速　　5.1　opcode緩存　5.2　解釋器擴展模塊　5.3　腳本跟蹤與分析第6章　瀏覽器緩存　6.1　別忘了瀏覽器　6.2　緩存協商　6.3　徹底消滅請求第7章　Web服務器緩存　7.1　URL映射　7.2　緩存響應內容　7.3　緩存文件描述符第8章　反向代理緩存　　8.1　傳統(tǒng)代理　8.2　何為反向　8.3　在反向代理上創(chuàng)建緩存　8.4　小心穿過代理　8.5　流量分配第9章　Web組件分離　　9.1　備受爭議的分離　9.2　因材施教　9.3　擁有不同的域名　9.4　瀏覽器并發(fā)數　9.5　發(fā)揮各自的潛力第10章　分布式緩存　10.1　數據庫的前端緩存區(qū)　10.2　使用memcached　10.3　讀操作緩存　10.4　寫操作緩存　10.5　監(jiān)控狀態(tài)　10.6　緩存擴展第11章　數據庫性能優(yōu)化　11.1　友好的狀態(tài)報告　11.2　正確使用索引　　11.3　鎖定與等待　11.4　事務性表的性能　11.5　使用查詢緩存　　11.6　臨時表　11.7　線程池　11.8　反范式化設計　　11.9　放棄關系型數據庫　第12章　Web負載均衡　12.1　一些思考　12.2　HTTP重定向　12.3　DNS負載均衡　12.4　反向代理負載均衡　12.5　IP負載均衡　　12.6　直接路由　12.7　IP隧道　　12.8　考慮可用性第13章　共享文件系統(tǒng)　13.1　網絡共享　13.2　NFS　　13.3　局限性第14章　內容分發(fā)和同步　14.1　復制　14.2　SSH　　14.3　WebDAV　　14.4　rsync　14.5　Hashtree　　14.6　分發(fā)還是同步　14.7　反向代理第15章　分布式文件系統(tǒng)　15.1　文件系統(tǒng)　15.2　存儲節(jié)點和追蹤器　15.3　MogileFS第16章　數據庫擴展　16.1　復制和分離　16.2　垂直分區(qū)　16.3　水平分區(qū)第17章　分布式計算　17.1　異步計算　17.2　并行計算第18章　性能監(jiān)控　18.1　實時監(jiān)控　18.2　監(jiān)控代理　18.3　系統(tǒng)監(jiān)控　18.4　服務監(jiān)控　18.5　響應時間監(jiān)控參考文獻　索引　

章節(jié)摘錄

　　第1章 緒論　　1.2 瓶頸在哪里　　相信你一定知道赤壁之戰(zhàn)，這是中國歷史上一場著名的以少勝多的戰(zhàn)役，東吳的任務是擊退曹操的進攻，要完成這項任務，可謂“萬事俱備，只欠東風”，這時東風便是決勝的瓶頸，所以很多系統(tǒng)論研究專家將其稱為“東風效應”，也就是社會心理學里講的“瓶頸效應”?！　≈苑Q它為瓶頸，是因為盡管東吳做了很多的戰(zhàn)前準備，包括蔣干中計導致曹操錯殺蔡瑁和張允、諸葛亮草船借箭、東吳苦練水軍等，但是僅靠這些仍無法獲得最終勝利，還需要最后的東南風才能一錘定音，完成火燒曹軍戰(zhàn)船的計劃。不過之前的準備工作都是勝利的子因素，而東南風這個關鍵因素最終和其他子因素一起相互作用，將整個戰(zhàn)斗的殺傷力無限放大?！　〔懿龠\氣不好，遇上東南風，倒了大霉，曹軍戰(zhàn)船一片火海，這時候東吳需要派出勇猛的陸軍部隊登岸攻下曹營，可是東吳向來精通水戰(zhàn)，幾乎沒有強大的陸戰(zhàn)部隊，只有老將黃蓋，這如何與曹操的精英騎兵抗衡呢？這個時候決勝的關鍵因素變成了劉備的盟軍支援，五虎上將各個威猛無比，身懷必殺絕技，此時正是上岸一顯身手的好機會，他們不費吹灰之力就將曹軍打得落花流水，試想如果沒有劉備的支援，赤壁一戰(zhàn)勝敗可能就撲朔迷離了。可見，系統(tǒng)性能的瓶頸，是指影響性能的關鍵因素，這個關鍵因素隨著系統(tǒng)的運行又會發(fā)生不斷的變化或遷移，比如由于站點用戶組成結構的多樣性和習慣的差異，導致在不同時段系統(tǒng)的瓶頸各不相同，又如站點在數據存儲量或瀏覽量增長到不同級別時，系統(tǒng)瓶頸也會發(fā)生遷移。一旦找到真正影響系統(tǒng)性能的主要因素，也就是性能瓶頸，就要堅決對其進行調整或優(yōu)化，因為你不得不這么做?！　√崾荆骸　≈嗅t(yī)是一門關于生命的哲學，也是中國人智慧的結晶，它的光芒在于獨到的思辨能力和系統(tǒng)性的分析方法，它認為世間萬物都在不停地變化，并賦予它們陰陽狀態(tài)，包括天地、季節(jié)、天氣、心理、生理等，而患者的病理也在隨之變化，所以，中醫(yī)會對同一位患者在不同季節(jié)進行不同的診斷，找到不同的病因?！　⊥瑫r，在這些關鍵因素的背后，也存在很多不能忽略的子因素，構成了性能優(yōu)化的“長尾效應”，也就是說如果你對某個子因素背后的問題進行優(yōu)化，可能會帶來性能上的少許提升，也許不被察覺，但是多個子因素的優(yōu)化結果也許會疊加在一起，帶來性能上可觀的提升。對于諸多子因素的優(yōu)化，需要稍加謹慎，花點時間考慮這種優(yōu)化是否值得，以及是否會帶來潛在的副作用，還有其他依賴的非技術因素?！　∪欢?，不論是關鍵因素還是子因素，它們的背后都是影響系統(tǒng)性能的問題所在，問題本身并不涉及關鍵性，只有在不同的系統(tǒng)和應用場景下，才會顯示出其是否關鍵?！　”菊碌钠溆嗖糠謱⑾攘谐鲆恍┪覀兘洺Ｓ龅降膯栴}，并簡單介紹我們常用的優(yōu)化方案，至于這些問題在什么時候是否關鍵，它們的本質是什么，以及如何調整或優(yōu)化，在后續(xù)章節(jié)中我們將結合具體場景來詳細探討包括這些在內的更多主題，這也是本書貫穿始終的線索?！　?.3 增加帶寬　　當Web站點的網頁或組件的下載速度變慢時，一些架構師可能想到的最省事的辦法就是增加服務器帶寬，因為他們認為是服務器帶寬不夠用了，對于一些以提供下載服務為主的站點來說也許是這樣的，但是對于其他服務的站點，你知道站點當前究竟使用了多少帶寬嗎？這些帶寬都用到哪里了呢？如何計算站點現在和可預見未來使用的帶寬？帶寬增加后下載速度就可以加快嗎？使用獨享帶寬和共享帶寬的本質區(qū)別是什么？如何節(jié)省帶寬？還有，你可能會忍無可忍地問，究竟什么是帶寬？　　對于帶寬的概念，如果你沒有仔細閱讀計算機網絡教材中的描述，我敢肯定你一定是完全憑借自己的理解來認識它的，因為這個詞實在是太有創(chuàng)意了，也實在太容易從字面理解了，但是這些認識從本質上講是完全錯誤的，正是基于這種誤解，很多人都無法完全解答上述那一連串問題，導致在所有涉及帶寬的問題上，只能依靠經驗和猜想。　　在后續(xù)章節(jié)中，我們將通過介紹數據的網絡傳輸原理，徹底揭開帶寬的本質，以及數據傳輸響應時間的依賴因素和計算方法。搞清楚這些一點都不困難，它們是一個優(yōu)秀架構師必須掌握的基礎知識?！　?.4 減少網頁中的HTTP請求　　我們知道Web站點中幾乎任何一個網頁都包含了多個組件，每個組件都需要下載、計算或渲染，毫無疑問，這些行為都會消耗時間。那么如果可以讓網頁減少這些行為，應該就可以加快網頁的展示速度，這是毫無疑問的，但是往往我們需要在優(yōu)雅的網頁表現和性能之間權衡取舍，這也許是美和快之間的博弈，找到最優(yōu)的均衡點至關重要，我們?yōu)榇俗隽撕芏鄧L試和努力：　　設計更加簡單的網頁，使其包含較少的圖片和腳本，但是這可能犧牲了美觀和用戶交互?！　⒍鄠€圖片合并為一個文件，利用CSS背景圖片的偏移技術呈現在網頁中，避免了多個圖片的下載?！　『喜avaScript腳本或者CSS樣式表：　　充分利用HTTP中的瀏覽器端Cache策略，減少重復下載。　　很顯然，這些技巧都來自于Web網頁前端的優(yōu)化，在后續(xù)章節(jié)中我們會有所涉及，但是不作為本書的重點來介紹，本書將更加偏重于站點服務器端的性能改善和規(guī)模擴展。　　1.5 加快服務器腳本計算速度　　我想大多數涉及性能問題的站點都會使用各種各樣的服務器端腳本語言，比如主流的PHP、Ruby、Python、ASP.NET、JSP等，這些腳本語言用來編寫動態(tài)內容或者后臺運行的小程序，已經成了幾乎所有站點的首選。而曾經使用C++編寫動態(tài)內容的經歷也讓我記憶猶新，除了每天都在感嘆c++的嚴謹和優(yōu)雅之外，我找不到其他任何好處。我們知道，用這些腳本語言編寫的程序文件需要通過相應的腳本解釋器進行解釋后生成中間代碼，然后依托在解釋器的運行環(huán)境中運行。所以生成中間代碼的這部分時間又成為大家為獲取性能提升而瞄準的一個目標，對于一些擁有較強商業(yè)支持的腳本語言，比如ASENET和JSP，均有內置的優(yōu)化方案，比如解釋器對某個腳本程序第一次解釋的時候，將中間代碼緩存起來，以供下次直接使用?！　τ陂_源類的腳本語言，也有很多第三方組件來提供此類功能，比如PHP的APC組件等。使用這些組件進行腳本優(yōu)化真的那么有用嗎？不同的應用效果是否有所不同呢？在后續(xù)章節(jié)中我們會詳細探討。　　1.6 使用動態(tài)內容緩存　　動態(tài)內容技術就像Web開發(fā)領域的一場工業(yè)革命，它帶來了產業(yè)升級和Web開發(fā)者的地位提升，在過去相當長一段時間里，大家普遍認為一個站點的技術含量主要體現在后臺的動態(tài)程序上，所以很多工程師都會帶著虛榮心警告你：“請叫我后臺開發(fā)工程師?！笔聦嵣线@種概念和偏見已經開始逐漸被歷史拋棄，但這不是我們此刻討論的重點?！　∽詣討B(tài)內容技術產生后，聰明的工程師們?yōu)榱藴p少動態(tài)內容的重復計算，想到了截取動態(tài)內容的勝利果實，將動態(tài)內容的HTML輸出結果緩存起來，在隨后的一段時間內當有用戶訪問時便跳過重復的動態(tài)內容計算而直接輸出?！　≡趯嶋H應用中，動態(tài)內容緩存可能是大家使用得最多的技術，但是并不見得所有的動態(tài)內容都適合使用網頁緩存，緩存帶來的性能提升恰恰與有些動態(tài)數據實時交互的需求形成矛盾，這是非常尷尬的，而解決該問題的唯一途徑不是技術本身，而是你如何權衡?！　×硪环矫?，緩存的實現還涉及了一系列非常現實的問題，即成千上萬的緩存文件如何存儲？緩存的命中率如何？緩存的過期策略如何設計？在擁有多臺Web服務器的分布式站點上應用動態(tài)內容緩存需要考慮什么呢？　　在后續(xù)章節(jié)中我們將詳細地探討這些問題?！　?.7 使用數據緩存　　動態(tài)內容緩存是將數據和表現整體打包，一步到位，但就像快餐店里的組合套餐一樣，有時候未必完全合乎我們的口味。當我們意識到在自己的站點中，某些動態(tài)內容的計算時間其實主要消耗在一些煩人的特殊數據上，這些數據或者更新過于頻繁，或者消耗大量的I/O等待時間，比如對關系數據庫中某字段的頻繁更新和讀取，這時我們?yōu)榱颂岣呔彺娴撵`活性和命中率，以及性能的要求，便開始考慮數據緩存?！　「蛹毩６鹊臄祿彺姹苊饬诉^期時大量相關網頁的整體更新，比如很多動態(tài)內容都包含了一段公用的數據，如果我們將整個頁面全部緩存，那么假如這段數據頻繁更新導致頻繁過期，無疑會使得所有網頁都要頻繁地重建緩存，這對網頁的其他部分內容似乎很不公平?！　　?/pre>








圖書封面



圖書標簽Tags
無




評論、評分、閱讀與下載



還沒讀過(62)
勉強可看(449)
一般般(766)
內容豐富(3178)
強力推薦(260)


 


    構建高性能Web站點 PDF格式下載