構建高性能web站點筆記一

構建高性能web站點筆記

第三章 服務器併發處理能力

3.1吞吐率

描述服務器在實際運行期間單位時間內處理的請求數。也就是必定併發用戶的狀況下，服務器處理請求能力的量化體現。

吞吐率的前提包括：

• 併發用戶數
• 總請求數
• 請求資源描述

第五章 動態腳本加速

微動態內容的計算結果生成緩存，咱們達到必定目的。

3.1 opcode緩存

目的減小CPU和內存開銷。若是動態內容的性能瓶頸不在CPU和內存，而在於I/O操做，好比數據庫查詢帶來的磁盤I/O開銷，那麼opcode cache的性能提高也有限。

如php，ruby，python這些解釋型語言，當解釋器完成對腳本代碼的分析後，便將他們生成能夠直接運行的中間代碼，也就是操做碼Operate Code,opcode。

對解釋型語言，從程序代碼到中間代碼的過程，咱們稱爲解釋(parse),由解釋器完成。

對編譯型語言，從程序代碼到中間代碼的過程，稱爲編譯（如C語言的gcc編譯器）。

編譯器和解釋器一個根本的不一樣是：解釋器在生成中間代碼之後，便直接執行，因此運行時的控制權在解釋器；而編譯器則將中間代碼進一步優化，生成能夠直接運行的目標程序，但不執行。用戶能夠在隨後的任意時間執行它，這時控制權在目標程序，和編譯器沒有任何關係。

php的核心引擎 Zend Engine

查看print 1+1;的opcode，經過分析，一共有5個操做：

三地址碼，是一種中間代碼的理想表現形式。每一個運算由不超過三個地址組成：op1,op2,result。

生成opcode

實際上，腳本代碼能夠看作一系列單詞的集合，這些單詞包括關鍵字，標識符，運算符等。

step1： 詞法分析，給全部的單詞分類，並打上記號（token），print對應的記號是T_PRINT詞法規則文件zend_language_scanner.1

setp2： 語法分析，將T_PRINT標記以及上下文替換成了zend_do_print()函數，該函數實現了到opcode的轉換，設置了opcode的指令以及op1的數據。

避免重複編譯

經過opcode緩存，避免重複的opcode編譯。

一些優秀的opcode緩存器擴展，好比php能夠選擇APC，XCache等。他們均可以將opcode緩存在共享內存中，而咱們幾乎不須要修改任何代碼。

5.2解釋器擴展模塊

好比在php中加載java擴展模塊，則吞吐率就會降低，帶來巨大開銷。

5.3腳本跟蹤與分析

爲了讓腳本執行更快，women那必須瞭解事件主要消耗在哪些代碼上。

Xdebug是一個PHP的PECL擴展，提供了一組用於代碼跟蹤和調試的API。
代碼執行事件、上下文信息收集等。
（沒有詳細看）

第六章 瀏覽器緩存

6.1瀏覽器

通常來講，瀏覽器的緩存都是在本地，內存中或者文件中。

6.2緩存協商

服務器端的動態內容緩存包括緩存內容的建立、存儲以及過時檢查等一系列過程。

瀏覽器緩存在瀏覽器本地，而內存由web服務器生成，任何一方都不能單獨完成這一系列過程。因此它們之間必須有一種溝通機制，這就是HTTP中的「緩存協商」。

HTTP協議定義的緩存機制有：

• Expires策略：Expires是Web服務器響應消息頭字段，在響應http請求時告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存取數據，而無需再次請求。
• Cache-control策略：Cache-Control與Expires的做用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據仍是從新發請求到服務器取數據。只不過Cache-Control的選擇更多，設置更細緻，若是同時設置的話，其優先級高於Expires。

• Last-Modified/If-Modified-Since：Last-Modified/If-Modified-Since要配合Cache-Control使用。

  Last-Modified：標示這個響應資源的最後修改時間。web服務器在響應請求時，告訴瀏覽器資源的最後修改時間。

  If-Modified-Since：當資源過時時（使用Cache-Control標識的max-age），發現資源具備Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。若最後修改時間較新，說明資源又被改動過，則響應整片資源內容（寫在響應消息包體內），HTTP 200；若最後修改時間較舊，說明資源無新修改，則響應HTTP 304 (無需包體，節省瀏覽)，告知瀏覽器繼續使用所保存的cache。

• Etag/If-None-Match： Etag/If-None-Match也要配合Cache-Control使用。
  Etag：web服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器以爲）。Apache中，ETag的值，默認是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後獲得的。

  If-None-Match：當資源過時時（使用Cache-Control標識的max-age），發現資源具備Etage聲明，則再次向web服務器請求時帶上頭If-None-Match （Etag的值）。web服務器收到請求後發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對，決定返回200或304。

  HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：

  • Last-Modified標註的最後修改只能精確到秒級，若是某些文件在1秒鐘之內，被修改屢次的話，它將不能準確標註文件的修改時間
  • 若是某些文件會被按期生成，當有時內容並無任何變化，但Last-Modified卻改變了，致使文件無法使用緩存
  • 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形

• 用戶行爲與緩存

  用戶操做	Expires/Cache-Control	Last-Modified/Etag
  地址欄回車	有效	有效
  頁面連接跳轉	有效	有效
  新開窗口	有效	有效
  前進/後退	有效	有效
  F5刷新	無效	有效
  ctrl+F5刷新	無效	無效

第七章 Web服務器緩存

7.1 URL映射

解析URL，完成從URL到實際內容或資源的映射。

7.2 緩存響應內容

存儲對應關係，在URL映射開始時檢查緩存，若是存在並處於有效期內，那麼直接取出並做爲響應內容返回給瀏覽器。

準備好緩存區

通常來講，緩存存儲在本機內存、磁盤或者分佈式存儲到其餘服務器的內存或者磁盤。

緩存內容

引入磁盤緩存後，本來指向動態內容的請求能夠迅速得到緩存

緩存文件描述符

對於靜態內容，特別是擁有大量小文件的站點， Web服務器至關大一部分開銷花在打開文件上，即Open()系統調用，因此咱們還能夠考慮將打開後的文件描述符直接緩存到Web服務器的內存中，固然，文件描述符是反應系統資源的數據結構，它也只能存在本機內存中。

Apache提供相應的擴展 mod_file_cache，他須要咱們提供但願緩存的文件列表，好比咱們配置：

CacheFile /data/www/htdocs/test.html

這樣一來，Apache在啓動的時候便會打開這些文件，並持續到Apache關閉爲止，在這期間，若是有對這些文件的請求，Apache將經過文件描述符直接把文件傳送出去。

顯然，這種緩存文件描述符的緩存方式只適用於靜態內容，並對於大文件不使用，由於處理他們的主要時間花在傳送數據上，而不是打開文件。

第八章 反向代理緩存

8.1定義

web服務器隱藏在代理服務器以後。實現這種機制的服務器，就稱爲反向代理服務器。

目的：基於緩存的加速。