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

作者簡介

郭欣，擁有10年以上的Web開發(fā)和架構(gòu)經(jīng)驗(yàn)，以及多年的創(chuàng)業(yè)經(jīng)歷。曾就職于騰訊公司，先后負(fù)責(zé)諸多Web產(chǎn)品的開發(fā)、架構(gòu)和技術(shù)管理，并致力于性能研究和實(shí)踐推廣。在加入騰訊之前，獲得國家系統(tǒng)分析師職稱。熱衷于創(chuàng)造簡單易用的互聯(lián)網(wǎng)產(chǎn)品，曾創(chuàng)建國內(nèi)知名性能監(jiān)控云服務(wù)“監(jiān)控寶”，并入選年度中國最受關(guān)注初創(chuàng)公司。愛好廣泛，喜歡搖滾音樂、賽車、旅游、電影，也曾是一名業(yè)余吉他手。

書籍目錄

第1章　緒論
1.1　等待的真相
1.2　瓶頸在哪里
1.3　增加帶寬
1.4　減少網(wǎng)頁中的HTTP請(qǐng)求
1.5　加快服務(wù)器腳本計(jì)算速度
1.6　使用動(dòng)態(tài)內(nèi)容緩存
1.7　使用數(shù)據(jù)緩存
1.8　將動(dòng)態(tài)內(nèi)容靜態(tài)化
1.9　更換Web服務(wù)器軟件
1.1　頁面組件分離
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章　動(dòng)態(tài)內(nèi)容緩存
4.1　重復(fù)的開銷
4.2　緩存與速度
4.3　頁面緩存
4.4　局部無緩存
4.5　靜態(tài)化內(nèi)容
第5章　動(dòng)態(tài)腳本加速
5.1　opcode緩存
5.2　解釋器擴(kuò)展模塊
5.3　腳本跟蹤與分析
第6章　瀏覽器緩存
6.1　別忘了瀏覽器
6.2　緩存協(xié)商
6.3　徹底消滅請(qǐng)求
第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　Hash
14.6　分發(fā)還是同步
14.7　反向代理
第15章　分布式文件系統(tǒng)
15.1　文件系統(tǒng)
15.2　存儲(chǔ)節(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)控
參考文獻(xiàn)
索引

章節(jié)摘錄

版權(quán)頁：   插圖：   往往也正是因?yàn)檫@些請(qǐng)求性質(zhì)的不同，Web服務(wù)器并發(fā)能力強(qiáng)弱的關(guān)鍵便在于如何針對(duì)不同的請(qǐng)求性質(zhì)來設(shè)計(jì)最優(yōu)并發(fā)策略，這在后續(xù)章節(jié)中會(huì)有詳細(xì)介紹。同時(shí)也是因?yàn)橛袝r(shí)候一臺(tái)服務(wù)器要同時(shí)處理諸多不同性質(zhì)的請(qǐng)求，在一定程度上使得Web服務(wù)器的性能無法充分發(fā)揮，這很容易理解，就像銀行對(duì)不同業(yè)務(wù)設(shè)立不同的窗口一樣，這些窗口的服務(wù)員分別熟悉自己的窗口業(yè)務(wù)，可以為不同的客戶分別快速辦理業(yè)務(wù)，但是如果讓這些窗口都可以辦理所有業(yè)務(wù)，也就是客戶可以去任何窗口辦理任何業(yè)務(wù)，那會(huì)怎么樣呢？相信沒有幾個(gè)銀行業(yè)務(wù)員會(huì)對(duì)所有的業(yè)務(wù)都輕車熟路，這樣勢(shì)必會(huì)影響到整體的業(yè)務(wù)辦理速度。 壓力測(cè)試的前提條件 如果我們要統(tǒng)計(jì)吞吐率，便存在一些潛在的前提，那就是壓力的描述和請(qǐng)求性質(zhì)的描述。壓力的描述一般包括兩部分，即并發(fā)用戶數(shù)和總請(qǐng)求數(shù)，也就是模擬多少個(gè)用戶同時(shí)向服務(wù)器發(fā)送多少個(gè)請(qǐng)求，隨后會(huì)有關(guān)于并發(fā)用戶數(shù)的詳細(xì)介紹。 請(qǐng)求性質(zhì)則是對(duì)請(qǐng)求的URL所代表的資源的描述，比如lKB大小的靜態(tài)文件，或者包含10次數(shù)據(jù)庫查詢的動(dòng)態(tài)內(nèi)容等。 所以，吞吐率的前提包括如下幾個(gè)條件： ?并發(fā)用戶數(shù) ?總請(qǐng)求數(shù) ?請(qǐng)求資源描述 并發(fā)用戶數(shù) 前面提到了并發(fā)用戶數(shù)，在我們開始進(jìn)行壓力測(cè)試之前，一定要弄明白它的含義。簡單地說，并發(fā)用戶數(shù)就是指在某一時(shí)刻同時(shí)向服務(wù)器發(fā)送請(qǐng)求的用戶總數(shù)。如此多的用戶同時(shí)請(qǐng)求服務(wù)器，顯然會(huì)給服務(wù)器帶來不小的壓力，這時(shí)你可能有一個(gè)實(shí)際的問題，假如100個(gè)用戶同時(shí)向服務(wù)器分別進(jìn)行10次請(qǐng)求，與1個(gè)用戶向服務(wù)器連續(xù)進(jìn)行1000次請(qǐng)求，效果一樣嗎？也就是說，給服務(wù)器帶來的壓力一樣嗎？ 雖然看起來服務(wù)器都需要連續(xù)處理1000個(gè)請(qǐng)求，其實(shí)關(guān)鍵的區(qū)別就在于，是否真的“連續(xù)”。首先有一點(diǎn)需要明白，對(duì)于壓力測(cè)試中提到的每一個(gè)用戶，連續(xù)發(fā)送請(qǐng)求實(shí)際上是指在發(fā)送一個(gè)請(qǐng)求并接收到響應(yīng)數(shù)據(jù)后再發(fā)送下一個(gè)請(qǐng)求。這樣一來，從微觀層面來看，1個(gè)用戶向服務(wù)器連續(xù)進(jìn)行1000次請(qǐng)求的過程中，任何時(shí)刻服務(wù)器的網(wǎng)卡接收緩沖區(qū)中只有來自該用戶的1個(gè)請(qǐng)求，而100個(gè)用戶同時(shí)向服務(wù)器分別進(jìn)行10次請(qǐng)求的過程中，服務(wù)器網(wǎng)卡接收緩沖區(qū)中最多有100個(gè)等待處理的請(qǐng)求，顯然，這時(shí)候服務(wù)器的壓力更大。 其實(shí)，并發(fā)用戶數(shù)這個(gè)詞你也許經(jīng)常聽到，很多時(shí)候它還有一些別名，比如并發(fā)數(shù)、并發(fā)連接數(shù)等。經(jīng)常會(huì)有人說某個(gè)Web服務(wù)器能支持多少并發(fā)數(shù)，除此之外，沒有任何上下文，這讓很多人摸不著頭腦，人們常常把并發(fā)用戶數(shù)和吞吐率混淆，實(shí)際上，它們并不是一回事，通過前面的介紹，我們很清楚，吞吐率是指在一定并發(fā)用戶數(shù)的情況下，服務(wù)器處理請(qǐng)求能力的量化體現(xiàn)。 那么，說一個(gè)服務(wù)器最多支持多少并發(fā)用戶數(shù)，這個(gè)“最多”到底是什么意思？這里我們暫且拋開技術(shù)的因素，從廣義的角度來看，舉個(gè)生活中的例子，比如某商城里有一個(gè)柜臺(tái)，給顧客們辦理業(yè)務(wù)。剛開始顧客稀少，一次只來一個(gè)顧客，柜臺(tái)業(yè)務(wù)員很輕松就可以搞定，不久，有很多顧客去柜臺(tái)辦理業(yè)務(wù)，大家排成一個(gè)長隊(duì)依次辦理，每個(gè)顧客在辦理業(yè)務(wù)的過程中，都需要花時(shí)間填寫一些資料，這時(shí)候其他顧客就得等著，而且柜臺(tái)業(yè)務(wù)員閑著無聊又不能干別的事情，所以他覺得很浪費(fèi)時(shí)間，就讓大家排成兩隊(duì)，這樣在等待的時(shí)候就給另一個(gè)隊(duì)辦理?？墒翘顚戀Y料的時(shí)間有點(diǎn)長，另一隊(duì)的顧客開始填寫資料時(shí)，前一個(gè)隊(duì)的顧客還沒填完，業(yè)務(wù)員還是得等。最后隊(duì)伍增加到了10隊(duì)，10個(gè)人同時(shí)辦理業(yè)務(wù)，剛好業(yè)務(wù)員不用等待任何顧客了，而且每個(gè)顧客對(duì)辦理速度也很滿意。 隨著前來辦理業(yè)務(wù)的顧客越來越多，業(yè)務(wù)員想做點(diǎn)有挑戰(zhàn)性的事情，他將隊(duì)伍增加到了20隊(duì)，同時(shí)給20個(gè)顧客辦理業(yè)務(wù)，這下20條隊(duì)伍擁擠不堪，原本輕松的保安為了維持秩序累得氣喘吁吁，這還不算，關(guān)鍵是業(yè)務(wù)員的辦理速度已經(jīng)趕不上大家填寫資料的速度了，一些人填完資料后沒人搭理，便開始抱怨，業(yè)務(wù)員也因?yàn)橥瑫r(shí)要給很多人辦理業(yè)務(wù)，腦子反應(yīng)不過來，導(dǎo)致處理原本熟悉的業(yè)務(wù)時(shí)也變得手忙腳亂，效率下降且時(shí)常伴隨一些低級(jí)失誤。 終于，在大家的一片聲討下，柜臺(tái)崩潰了。注意，柜臺(tái)的崩潰不是因?yàn)闃I(yè)務(wù)員無法繼續(xù)工作了，雖說他忙得累死累活，但是活兒還得干啊，關(guān)鍵是顧客們等得不耐煩了，大部分顧客都無法忍受長時(shí)間的等待以及辦理過程中出現(xiàn)的錯(cuò)誤，所以投訴到了商城的管理處，商城只好暫時(shí)關(guān)閉柜臺(tái)業(yè)務(wù)，商討對(duì)策。 很快，商城又恢復(fù)了柜臺(tái)業(yè)務(wù)，將柜臺(tái)的隊(duì)伍數(shù)調(diào)整到10隊(duì)，同時(shí)根據(jù)顧客流量，臨時(shí)增設(shè)一定數(shù)量的柜臺(tái)，這樣一來，顧客們紛紛表示滿意。 我們可以說，這個(gè)柜臺(tái)支持的最大并發(fā)數(shù)為10，因?yàn)榍『迷谶@個(gè)并發(fā)數(shù)下，柜臺(tái)業(yè)務(wù)開展得非常成功，顧客們都對(duì)服務(wù)時(shí)間非常滿意，而且此時(shí)代表業(yè)務(wù)辦理次數(shù)的柜臺(tái)吞吐率也比較高，商城和顧客實(shí)現(xiàn)雙贏。當(dāng)并發(fā)數(shù)少于10的時(shí)候，柜臺(tái)業(yè)務(wù)員的時(shí)間得不到充分利用，浪費(fèi)了柜臺(tái)的寶貴資源，這時(shí)候的吞吐率要低一些。而當(dāng)并發(fā)數(shù)大于10的時(shí)候，事實(shí)證明，顧客們不樂意了。這樣看來，問題的本質(zhì)變得非常清晰，似乎就是商家和顧客的博弈，而且是合作型博弈，最大并發(fā)數(shù)便是博弈的結(jié)果，也是最大程度的共贏。 可見，通常所講的最大并發(fā)數(shù)是有一定利益前提的，那就是服務(wù)器和用戶雙方所期待的最大收益，服務(wù)器希望支持高并發(fā)數(shù)及高吞吐率，而用戶不管那么多，只希望等待較少的時(shí)間，或者得到更快的下載速度，顯然，雙方不可能都徹底滿足，所以便存在討價(jià)還價(jià)的余地，同時(shí)雙方也都有能夠忍受的最低尺度。從經(jīng)濟(jì)學(xué)的角度看，就這么簡單，所以找到雙方利益的平衡點(diǎn)，便是我們所希望的最大并發(fā)用戶數(shù)。這種現(xiàn)象在后續(xù)章節(jié)中介紹下載服務(wù)的時(shí)候還會(huì)提到。 當(dāng)然，經(jīng)過權(quán)衡后，我們所希望的最大并發(fā)用戶數(shù)還存在一定的技術(shù)制約，這也是狹義層面的最大并發(fā)數(shù)的定義。柜臺(tái)的故事只是一個(gè)簡單的模型，而在我們?cè)L問實(shí)際的Web站點(diǎn)時(shí)，每個(gè)請(qǐng)求的處理過程并不像柜臺(tái)業(yè)務(wù)員給顧客辦理業(yè)務(wù)那么簡單，尤其是在并發(fā)用戶數(shù)較大的情況下，Web服務(wù)器使用什么樣的并發(fā)策略，是影響最大并發(fā)數(shù)的關(guān)鍵。 另外值得說明的是，即使我們通過壓力測(cè)試得出服務(wù)器支持的最大并發(fā)數(shù)，但這與實(shí)際并發(fā)用戶數(shù)卻是兩回事，因?yàn)橛卸嗌儆脩敉瑫r(shí)發(fā)來請(qǐng)求并不是服務(wù)器所能決定的，該來的總是要來，那是客觀存在的。一旦實(shí)際并發(fā)用戶數(shù)大于服務(wù)器所能支持的最大并發(fā)數(shù)，那必然造成一部分用戶需要等待超過預(yù)期的時(shí)間，影響了站點(diǎn)的服務(wù)質(zhì)量。所以，得出最大并發(fā)數(shù)的意義，在于了解服務(wù)器的承載能力，并且結(jié)合用戶規(guī)模考慮適當(dāng)?shù)臄U(kuò)展方案。從站點(diǎn)的某些商業(yè)角度來看，最大并發(fā)用戶數(shù)的支持程度往往比吞吐率更加容易理解。 在考慮實(shí)際用戶規(guī)模的時(shí)候，我們還需要了解一點(diǎn)，用戶訪問Web站點(diǎn)通常使用瀏覽器，而瀏覽器在下載一個(gè)網(wǎng)頁以及網(wǎng)頁中的多個(gè)組件時(shí)，采用多線程的并發(fā)下載方式，但是對(duì)于同一域名下URL的并發(fā)下載數(shù)是有最大限制的，具體限制視瀏覽器的不同而不同，比如，在：HTTP／1.1下，IE 7支持兩個(gè)并發(fā)連接，IE 8支持6個(gè)并發(fā)連接，F(xiàn)irefox 3支持4個(gè)并發(fā)連接，我們使用諸如HttpWateh這樣的HTTP監(jiān)視工具可以很清晰地看到這一點(diǎn)。所以，我們前面說到的服務(wù)器支持的最大并發(fā)數(shù)，具體到真實(shí)的用戶，可能并不是一對(duì)一的關(guān)系，一個(gè)真實(shí)的用戶可能會(huì)給服務(wù)器帶來兩個(gè)或更多的并發(fā)用戶數(shù)的壓力，一些高明的用戶還可以通過一些方法來修改瀏覽器的并發(fā)數(shù)限制。而我們?cè)诒緯袨榱撕喕Ｐ?，暫且認(rèn)為每個(gè)用戶的并發(fā)下載數(shù)均為1。 另一方面，從Web服務(wù)器的角度來看，實(shí)際并發(fā)用戶數(shù)也可以理解為Web服務(wù)器當(dāng)前維護(hù)的代表不同用戶的文件描述符總數(shù)，也就是并發(fā)連接數(shù)，當(dāng)然，不是同時(shí)來了多少用戶請(qǐng)求就建立多少連接，Web服務(wù)器一般會(huì)限制同時(shí)服務(wù)的最多用戶數(shù)，比如Apache的MaxClients參數(shù)，所以這個(gè)實(shí)際并發(fā)用戶數(shù)，有時(shí)候大于服務(wù)器所維護(hù)的文件描述符總數(shù)，而多出的這些用戶請(qǐng)求，則在服務(wù)器內(nèi)核的數(shù)據(jù)接收緩沖區(qū)中等待處理，所以這些請(qǐng)求在用戶看來處于阻塞狀態(tài)。

編輯推薦

《構(gòu)建高性能Web站點(diǎn)(修訂版)》充分應(yīng)用跨學(xué)科知識(shí)和科學(xué)分析方法，通過寬泛的視野和獨(dú)特的角度，將《構(gòu)建高性能Web站點(diǎn)(修訂版)》的內(nèi)容展現(xiàn)得更加透徹和富有趣味。此書深入分析了常見的高性能Web技術(shù)的方法和原理，內(nèi)容豐富，文字生動(dòng)，對(duì)比形象，對(duì)搭建高性能Web站點(diǎn)具備很強(qiáng)的可操作性。

名人推薦

本書是作者在Web系統(tǒng)領(lǐng)域多年工作、實(shí)踐和探索的結(jié)晶。本書涉及了Web系統(tǒng)優(yōu)化的各個(gè)方面，從瀏覽器、Cactle到Web、數(shù)據(jù)庫和分布式文件系統(tǒng)等；穿插了大量的實(shí)際測(cè)試數(shù)據(jù)和很多流行開源軟件的使用方法與案例；內(nèi)容豐富，文字生動(dòng)，對(duì)比形象。對(duì)于網(wǎng)絡(luò)系統(tǒng)架構(gòu)師、運(yùn)維和開發(fā)人員，這是很好的參考書目；對(duì)于想了解Web性能并希望動(dòng)手實(shí)踐的人員，這是由淺入深的學(xué)習(xí)書籍。 ——章文嵩博士，LVS作者，Linux內(nèi)核作者之一 本書深入分析了常見的高性能Web技術(shù)的方法和原理，對(duì)搭建高性能Web站點(diǎn)具備很強(qiáng)的可操作性。 ——張松國，騰訊網(wǎng)技術(shù)總監(jiān) 這是一個(gè)令人興奮的領(lǐng)域，這一系列準(zhǔn)則和方法在TopN的互聯(lián)網(wǎng)公司中都有大規(guī)模的實(shí)踐和應(yīng)用，作者在書中進(jìn)行了詳細(xì)而量化的論述。如果你正在為日益龐大的應(yīng)用而手足無措，那么你唯一要做的就是擁有這本書，并且實(shí)踐它。 ——朱鑫，MemcacheD8作者 新浪網(wǎng)研發(fā)中心平臺(tái)部高級(jí)工程師 互聯(lián)網(wǎng)寄托著我們的夢(mèng)想，它改變了人們的生活，從社交網(wǎng)站到網(wǎng)絡(luò)游戲，從搜索引擎到電子商務(wù)，成功的秘訣在于如何構(gòu)建高性能Web站點(diǎn)。郭欣在這本書中幾乎涵蓋了Webt性能優(yōu)化的所有內(nèi)容，并從多個(gè)角度進(jìn)行了全面的闡述，你可以通過其通俗易懂的文字，深入理解高性能站點(diǎn)架構(gòu)的真相并開拓視野，從而對(duì)性能瓶頸對(duì)癥下藥。本書可謂是高性能站點(diǎn)的必讀精作。 ——沈翔，GGoogle Developer Advocate，加州總部

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

---

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

---