構(gòu)建高性能Web站點(diǎn)

內(nèi)容概要

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

作者簡介

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

書籍目錄

第1章　緒論　　1.1　等待的真相　1.2　瓶頸在哪里　1.3　增加帶寬　1.4　減少網(wǎng)頁中的HTTP請求　1.5　加快服務(wù)器腳本計(jì)算速度　1.6　使用動態(tài)內(nèi)容緩存　1.7　使用數(shù)據(jù)緩存　1.8　將動態(tài)內(nèi)容靜態(tài)化　1.9　更換Web服務(wù)器軟件　1.10　頁面組件分離　1.11　合理部署服務(wù)器　1.12　使用負(fù)載均衡　1.13　優(yōu)化數(shù)據(jù)庫　1.14　考慮可擴(kuò)展性　1.15　減少視覺等待第2章　數(shù)據(jù)的網(wǎng)絡(luò)傳輸　2.1　分層網(wǎng)絡(luò)模型　2.2　帶寬　2.3　響應(yīng)時(shí)間　2.4　互聯(lián)互通第3章　服務(wù)器并發(fā)處理能力　3.1　吞吐率　3.2　CPU并發(fā)計(jì)算　3.3　系統(tǒng)調(diào)用　3.4　內(nèi)存分配　3.5　持久連接　3.6　I/O模型　3.7　服務(wù)器并發(fā)策略第4章　動態(tài)內(nèi)容緩存　　4.1　重復(fù)的開銷　4.2　緩存與速度　4.3　頁面緩存　4.4　局部無緩存　4.5　靜態(tài)化內(nèi)容第5章　動態(tài)腳本加速　　5.1　opcode緩存　5.2　解釋器擴(kuò)展模塊　5.3　腳本跟蹤與分析第6章　瀏覽器緩存　6.1　別忘了瀏覽器　6.2　緩存協(xié)商　6.3　徹底消滅請求第7章　Web服務(wù)器緩存　7.1　URL映射　7.2　緩存響應(yīng)內(nèi)容　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ā)數(shù)　9.5　發(fā)揮各自的潛力第10章　分布式緩存　10.1　數(shù)據(jù)庫的前端緩存區(qū)　10.2　使用memcached　10.3　讀操作緩存　10.4　寫操作緩存　10.5　監(jiān)控狀態(tài)　10.6　緩存擴(kuò)展第11章　數(shù)據(jù)庫性能優(yōu)化　11.1　友好的狀態(tài)報(bào)告　11.2　正確使用索引　　11.3　鎖定與等待　11.4　事務(wù)性表的性能　11.5　使用查詢緩存　　11.6　臨時(shí)表　11.7　線程池　11.8　反范式化設(shè)計(jì)　　11.9　放棄關(guān)系型數(shù)據(jù)庫　第12章　Web負(fù)載均衡　12.1　一些思考　12.2　HTTP重定向　12.3　DNS負(fù)載均衡　12.4　反向代理負(fù)載均衡　12.5　IP負(fù)載均衡　　12.6　直接路由　12.7　IP隧道　　12.8　考慮可用性第13章　共享文件系統(tǒng)　13.1　網(wǎng)絡(luò)共享　13.2　NFS　　13.3　局限性第14章　內(nèi)容分發(fā)和同步　14.1　復(fù)制　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é)點(diǎn)和追蹤器　15.3　MogileFS第16章　數(shù)據(jù)庫擴(kuò)展　16.1　復(fù)制和分離　16.2　垂直分區(qū)　16.3　水平分區(qū)第17章　分布式計(jì)算　17.1　異步計(jì)算　17.2　并行計(jì)算第18章　性能監(jiān)控　18.1　實(shí)時(shí)監(jiān)控　18.2　監(jiān)控代理　18.3　系統(tǒng)監(jiān)控　18.4　服務(wù)監(jiān)控　18.5　響應(yīng)時(shí)間監(jiān)控參考文獻(xiàn)　索引　

章節(jié)摘錄

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








圖書封面



圖書標(biāo)簽Tags
無




評論、評分、閱讀與下載



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


 


    構(gòu)建高性能Web站點(diǎn) PDF格式下載