apache-優化

時間 2019-11-09

標籤 apache 優化欄目 Apache 简体版

原文原文鏈接

優化

性能優化
指定mpm模式（編譯時）javascript

httpd -V show compile settings 及 Server MPM
-l Compiled in modules ,是否有worker.c 不然爲preworkphp

apache 計算內存消耗
在壓力測試時，找到httpd進程，查看一個進程使用了多少的內存，而後看看總的進程html

Apache內存使用量可使用下面命令：
ps -U apache u|awk '{S+=$6} END {print S}'
優化Apache(httpd)
KeepAlive 是否容許持續鏈接
MaxKeepAliveRequests 容許的持續鏈接的最大數
KeepAliveTimeout 持續鏈接在沒有請求多少秒後切斷
StartServers 最初啓動時啓動多少個服務器進程
MinSpareServers 空閒服務器進程的最小數
MaxSpareServers 空閒服務器進程的最大數
MaxRequestsPerChild 每一個子進程處理的最大請求數java

VPS優化Apache徹底設置node

1、削減模塊以及計算調整可供APACHE使用的內存c++

影響WEB服務器最大的因素即爲內存，因此咱們把它放在最前面web

在默認狀態下，Apache會分配最大256個併發客戶端鏈接，或者256個進程（每個都對應一個請求）。按照這種設置，一個流量巨大的網站會在頃刻間崩潰（即便你假設每一個進程佔用5MB內存，那也須要1.3GB的內存來知足請求的數量）。若是不採起其它措施，系統會經過硬盤來嘗試使用交換空間以處理它無法在物理內存中完成的任務。正則表達式

因此，咱們須要修改httpd.conf，使它使用最小的模塊集
修改httpd.conf文件，保留
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule php5_module modules/libphp5.so
LoadModule fastcgi_module modules/mod_fastcgi.so數據庫

去掉其它的模塊apache

咱們配置的VPS服務器，系統加LAMP程序啓動後總共在300M左右的內存，你可能但願要求50％的物理內存都供Apache使用，這樣，你須要肯定可讓httpd真正使用的內存數。

首先準確計算出apache佔用的進程數

ps -ef|grep httpd

root 21678 1 0 Jul19 ? 00:00:00 /usr/local/apache//bin/httpd -k start
vuser 21679 21678 0 Jul19 ? 00:00:00 /usr/local/apache//bin/httpd -k start
vuser 21714 21678 0 Jul19 ? 00:00:07 /usr/local/apache//bin/httpd -k start
vuser 21855 21678 0 Jul19 ? 00:00:07 /usr/local/apache//bin/httpd -k start
看apache是以什麼用戶啓動的，而後咱們再用

ps -U vuser -u vuser u

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
vuser 29838 0.0 0.0 200404 5580 ? S 11:29 0:00 /usr/local/apache//bin/fcgi- -k start
vuser 29845 0.0 0.0 879952 7592 ? Sl 11:29 0:00 /usr/local/apache//bin/httpd -k start
vuser 29851 0.0 0.0 879952 7592 ? Sl 11:29 0:00 /usr/local/apache//bin/httpd -k start
(注：通常是用# ps -U apache -u apache u察看，但我這裏運行apache的是vuser用戶）

我們看到單個httpd進程使用了7.6 MB的RSS（駐留集大小）內存以及最大爲88M左右的VSZ(虛擬內存)，這固然在很大程度上取決於你在Apache里加載和運行的模塊數量。這決不是一個固定的數字。因爲這個數字裏還包含了共享庫包，因此不是100％的準確。咱們能夠認爲RSS數字的一半是httpd線程真正使用的內存數，這可能還有點保守，可是離咱們的目的已經很是接近了，這樣，咱們HTTPD線呈使用的內存數即爲8M/2=4M

說明：MinSpareservers和MaxSpareServers分別設置空閒子進程的最小和最大數量，StartServers設置了服務器啓動時創建的子進程數量。
ServerLimit 則是控制MaxClients所能使用的最大值。縮減MaxClients能讓運行動態內容（好比：Drupal）的服務器有很大的改變。若是你的VPS 遭遇到流量的大幅增長，而你的MaxClients設置的過高的話，你的服務器將會無限循環工做於從物理內存交換頁面到虛擬內存中，最終致使宕機。通常計算適當的MaxClients值取決於你總共可用的系統內存除於每一個Apache進程使用的內存。

計算MaxClient
MaxClients＝(總內存－預留內存)/單個APACHE子進程使用的內存。
那麼咱們的1GRAM的VPS服務器的MaxClient即爲：
MaxClients＝(1024-512)/4=128個

設置MaxRequestsPerChild

MaxRequestsPerChild 設置的是每一個子進程能夠處理的請求數。每一個子進程在處理了MaxRequestsPerChild個請求後將自動銷燬。0意味着無限，即子進程永不銷燬。雖然缺省設爲0可使每一個子進程處理更多的請求，但若是設成非零值也有兩點重要的好處：

一、可防止意外的內存卸漏；
二、在服務器負載降低的時侯會自動減小子進程數。

所以，可根據服務器的負載來調整這個值，若是非零的話，vps上我的認爲1000左右是比較合適的。事實上這個值對Apache的性能影響不是很大。

如下是本人在1G內存的VPS上經常使用的配置

StartServers 5
MinSpareServers 5
MaxSpareServers 20
ServerLimit 128
MaxClients 128
MaxRequestsPerChild 1000

它們要根據你的VPS的大小和你的Apache進程大小等來決定。

備註：
HostnameLookups 最好設置爲off，不然會帶來延遲，由於對每個請求都須要做一次DNS查詢。若是你使用了任何」Allow from domain」或」Deny from domain」指令(也就是domain使用的是主機名而不是IP地址)，則代價是要進行兩次DNS查詢(一次正向和一次反向，以確認沒有做假)。因此，爲了獲得最高的性能，應該避免使用這些指令(不用域名而用IP地址也是能夠的)。若是網站空間中沒有使用 Options FollowSymLinks，Apache就必須執行額外的系統調用以驗證符號鏈接。爲了不這種狀況應該在全部地方都設置 FollowSymLinks。若是設置AllowOverride all，則Apache會試圖對文件名的每個組成部分都打開.htaccess，如無必要應該對文件系統中全部的地方都使用 AllowOverride None。在Apache2.0可以忽略將要被髮送的文件的內容的時候(好比發送靜態內容)，若是操做系統支持sendfile() ，則Apache將使用內核提供的sendfile()來發送文件。使用sendfile能夠經過免除分離的讀和寫操做來提高性能。咱們能夠經過設置 EnableSendfile on來開啓它。

2、優化KeepAlive

KeepAlive容許你的訪問者在同一個TCP鏈接上完成多個請求，理論上它有助於提高反應時間，由於你的訪問者能夠在同一個鏈接上請求你的網頁，圖片和 javascripts。遺憾地是，Apache對於每一個請求都須要一個工做進程去處理。默認的每一個工做進程將持續打開15秒來處理每一個請求，即便你的訪問者已經再也不使用它了！這也就意味着你的系統在任什麼時候間都是缺乏工做進程的。咱們都但願咱們那只有有限資源的小VPS能有確實在工做的工做進程。實現的方法之一是關閉KeepAlive。在你的httpd.conf文件中找到下面的一行：
KeepAlive On
而後將它改變爲：
KeepAlive Off
若是你的網站有大量的圖片和javascripts，一般最好仍是讓KeepAlive保持打開，而後作些調整。
若是你決定讓KeepAlive保持打開狀態，改變默認的KeepAliveTimeout值就顯得很重要了。它能避免鏈接沒有在使用時仍然打開。在你的httpd.conf文件中找到下面一行：
KeepAliveTimeout 15
你只但願鏈接打開5秒鐘，這已經足夠用戶打開大部分必須的文件。因此改變此行爲：
KeepAliveTimeout 5
若是你但願讓KeepAlive保持打開狀態，同時應該增長MaxKeepAliveRequests。設置它爲更大的值讓每一個鏈接能夠處理更多的請求，從而增長效率。找到這行：
MaxKeepAliveRequests 100
改變爲：
MaxKeepAliveRequests 200

3、調整Timeout

另外一個較小的調整是改變TimeOut指令，這個調整能夠獲得小的性能提高和減少DDOS攻擊的效果。這個指令用於設置Apache當接收新請求，處理請求和返回響應前需等待多少秒。找到這行：
Timeout 120
改變爲：
Timeout 60

安裝-基本配置

apache 4-19
下載後校驗
md5sum -c xxxx.md5
升級apr 和apr-util
編譯腳本參數
mod_deflate 由 zlib-dev 提供

啓動腳本
cat apachectl 爲腳本連接到etc/init.d 而後來連接至rc3.d rc.6.d

服務模式
獨立模式和inetd模式
默認獨立模式，效率高
inetd 超級服務，適合訪問量較小
httd進程號在log/httpd.pid
kill log/httpd.pid

運行多個服務器
編譯時指定安裝目錄
./configure --prefix=

httpd -l 列出編譯的模塊
查看httpd 工做模型
1，httpd -l 通常默認prefork
2，httpd -V

1，自帶的監視器
mod_status
LoadModule status_module modules/mod_status.so #可加載
配置文件添加
131
132 SetHandler server-status
133 Order Allow,Deny
134 Allow from all
135
136
137 ExtendedStatus On

訪問http://yourname/server-status?refresh
配置 mod_info 提供服務器的配置信息

字段                         說明
Server Version       Apache 服務器的版本。
Server Built         Apache 服務器編譯安裝的時間。
Current Time        目前的系統時間。
Restart Time         Apache 從新啓動的時間。
Parent Server Generation        Apache 父程序 (parent process) 的世代編號，就是 httpd 接收到 SIGHUP 而從新啓動的次數。
Server uptime         Apache 啓動後到如今通過的時間。
Total accesses         到目前爲此 Apache 接收的聯機數量及傳輸的數據量。
CPU Usage           目前 CPU 的使用情形。
_SWSS....            全部 Apache process 目前的狀態。每個字符表示一個程序，最多能夠顯示 256 個程序的狀態。
Scoreboard Key         上述狀態的說明。如下爲每個字符符號所表示的意義：
    * _：等待連結中。
    * S：啓動中。
    * R：正在讀取要求。
    * W：正在送出迴應。
    * K：處於保持聯機的狀態。
    * D：正在查找DNS。
    * C：正在關閉連結。
    * L：正在寫入記錄文件。
    * G：進入正常結束程序中。
    * I：處理閒置。
    * .：尚無此程序。
Srv        本程序與其父程序的世代編號。
PID        本程序的process id。
Acc        分別表示本次聯機、本程序所處理的存取次數。
M         該程序目前的狀態。
CPU        該程序所耗用的CPU資源。
SS         距離上次處理要求的時間。
Req        最後一次處理要求所耗費的時間，以千分之一秒爲單位。
Conn       本次聯機所傳送的數據量。
Child       由該子程序所傳送的數據量。
Slot        由該 Slot 所傳送的數據量。
Client       客戶端的地址。
VHost       屬於哪個虛擬主機或本主機的IP。
Request     聯機所提出的要求信息。

2，顯示服務器版本
ServerTokens Prod[uctOnly] ：Server: Apache
使用curl -I IP 測試

3，持久鏈接 http/1.1
設置：KeepAlive On|Off
KeepAliveTimeout 15
測試
GET /URL HTTP/1.1
Host: 2.2.2.1

4，靜態編譯的模塊
httpd -l
動態加載模塊
Include conf.modules.d/*.conf
httpd -M | grep 模塊
模塊文件路徑可以使用相對路徑：相對於ServerRoot（默認/etc/httpd）

5，站點訪問控制

可基於兩種機制指明對哪些資源進行何種訪問控制
訪問控制機制有兩種：客戶端來源地址，用戶帳號

》文件系統路徑
<Directory 「/path">
...

<File 「/path/file」>
...

<FileMatch "PATTERN">
...

》 url 路徑

<Location "">
...

<LocationMatch "">
...

示例

帶match 爲正則匹配

6，中「基於源地址」實現訪問控制

(1) Options：後跟1個或多個以空白字符分隔的選項列表
在選項前的+，- 表示增長或刪除指定選項
常見選項：
Indexes：指明的URL路徑下不存在與定義的主頁面資源相符的資
源文件時，返回索引列表給用戶
FollowSymLinks：容許訪問符號連接文件所指向的源文件（mv /etc/httpd/conf.d/welcome.conf{,.bk}）
None：所有禁用
All：所有容許

(2) AllowOverride

與訪問控制相關的哪些指令能夠放在指定目錄下的.htaccess（由
    AccessFileName指定）文件中，覆蓋以前的配置指令
    只對<directory>語句有效
    AllowOverride All: .htaccess中全部指令都有效
    AllowOverride None： .htaccess 文件無效
    AllowOverride AuthConfig .htaccess 文件中，除了AuthConfig 其它指
    令都沒法生效

(3) 基於IP的訪問控制:
無明確受權的目錄，默認拒絕
容許全部主機訪問：Require all granted
拒絕全部主機訪問：Require all denied
控制特定的IP訪問：
Require ip IPADDR：受權指定來源的IP訪問
Require not ip IPADDR：拒絕特定的IP訪問
控制特定的主機訪問：
Require host HOSTNAME：受權特定主機訪問
Require not host HOSTNAME：拒絕
HOSTNAME：
FQDN：特定主機
domin.tld：指定域名下的全部主機
不能有失敗，至少有一個成功匹配才成功，即失敗優先

Require all granted
Require not ip 172.16.1.1 拒絕特定IP

多個語句有一個成功，則成功，即成功優先

Require all denied
require ip 172.16.1.1 容許特定IP

日誌配置：
      錯誤：
           ErrorLog logs/error_log
            LogLevel warn
            LogLevel 可選值: debug, info, notice, warn,error, crit, alert, emerg
                      
      訪問日誌：
      定義日誌格式：LogFormat format strings
         LogFormat "%h %l %u %{%F %T}t \"%r\" %>s %b \"%{Referer}i\"
        \"%{User-Agent}i\""  testlog
        使用日誌格式
        CustomLog logs/access_log testlog

7，定義路徑別名：
Alias /URL/ "/PATH/" 訪問url 匹配後改寫至path

8，基於用戶訪問控制
認證質詢：WWW-Authenticate：響應碼爲401，拒絕客戶端請求，並說明要求客戶端提供帳號和密碼
認證：Authorization：客戶端用戶填入帳號和密碼後再次發送請求報文；認證經過時，則服務器發送響應的資源
認證方式兩種：basic：明文
digest：消息摘要認證,兼容性差

用戶的帳號和密碼
    虛擬帳號：僅用於訪問某服務時用到的認證標識
    存儲：文本文件，SQL數據庫，ldap目錄存儲，nis等

配置示例：
<Directory 「/path">
Options None
AllowOverride None
AuthType Basic
AuthName "String「 # 提示字符
AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE" #建立隱藏文件，文件使用ACL添加apache 訪問權限 chmod 0600
Require user username1 username2 ...

容許帳號文件中的全部用戶登陸訪問：Require valid-user
在某一目錄下建立密碼文件，AuthUserFile
htpasswd [options] /PATH/HTTPD_PASSWD_FILE username
第一次加-c 建立文件，隨後不用加選項

使用.htacesss
AuthType Basic
AuthName "String「 # 提示字符
AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE" #建立隱藏文件，文件使用ACL添加apache 訪問權限 chmod 0600
Require user username1 username2 ...
在受控目錄下添加
allowoverride authconfig

基於組帳號配置
  (1) 定義安全域
    <Directory 「/path">
    AuthType Basic
    AuthName "String「
    AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE"
    AuthGroupFile "/PATH/HTTPD_GROUP_FILE"
    Require group grpname1 grpname2 ...
    </Directory>
   (2) 建立用戶帳號和組帳號文件
    組文件：每一行定義一個組
    GRP_NAME: username1 username2 ..
           
       遠程客戶端和用戶驗證的控制
         Satisfy ALL|Any
        ALL 客戶機IP和用戶驗證都須要經過才能夠
        Any客戶機IP和用戶驗證,有一個知足便可 
                           
        Require valid-user
        <RequireAll>
        Require all granted
        Require not ip 172.16.1.1
         </RequireAll>
        Satisfy Any   
            
    實現用戶家目錄的http共享        
            基於模塊mod_userdir.so實現
            相關設置：
            vim /etc/httpd/conf.d/userdir.conf
            <IfModule mod_userdir.c>
            #UserDir disabled
            UserDir public_html #指定共享目錄的名稱
            </IfModule>
            準備目錄
            su – wang;mkdir ~/public_html
            setfacl –m u:apache:x ~wang
            訪問
             http://localhost/~wang/index.html
             
       ServerSignature On | Off | EMail  
        訪問的網頁不存在，顯示服務器類型及端口，使用mail 會調用程序寫mail  mail地址有
             ServerAdmin www-admin@foo.example.com  控制
    
    
  
             
             
             
            容器處理順序

1 與，htacess
2
3
4

FAST-cgi 常駐內存獨立於服務器，崩潰後不會影響到服務器自己
更安全，擴展性，同時處理多個請求
缺點：

別名，重定向
mod_alias
可將下載重定向至其餘主機
permanent 301
temp 302
seeother 303
gone 410
redirect
redirectmatch 容許正則表達式

中止與重啓
信號term
當即 kill -TERM cat /usr/local/apache2/logs/httpd.pid
信號 USER1
優雅重啓 apachectl -k graceful
父進程建議子進程在完成它們如今的請求後退出
父進程從新讀入配置文件並從新打開日誌文件。每當一個子進程死掉，父進程馬上用新的配置文件產生一個新的子進程並馬上開始伺服新的請求

信號 HUP 當即重啓
apachectl -k restart

信號：WINCH
apachectl -k graceful-stop
WINCH或graceful-stop信號使得父進程建議子進程在完成它們如今的請求後退出(若是他們沒有進行服務，將會馬上退出)。而後父進程刪除PidFile並中止在全部端口上的監聽。父進程仍然繼續運行並監視正在處理請求的子進程，一旦全部子進程完成任務並退出或者超過由GracefulShutdownTimeout指令規定的時間，父進程將會退出。在超時的狀況下，全部子進程都將接收到TERM信號並被強制退出

ps -U apache u | wc -l
sed -nr '/StartServers/,~6p' /etc/httpd/conf/httpd.conf

查看持續的輸出
tail -f /var/log/httpd/error_log

vhost&mpm

apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) * 2
apache_max_process = apache_max_process_with_good_perfermance * 1.5

ps aux|grep -v grep|awk '/httpd/{sum+=$6;n++};END{print sum/n}'

工做模式
prefork
多進程I/O模型，每一個進程響應一個請求，默認模型
一個主進程：生成和回收n個子進程，建立套接字，不響應請求
多個子進程：工做work進程，每一個子進程處理一個請求；系統初始時，預先生成多個空閒進程，等待請求，最大不超過1024個

prefork的配置：
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256 最多進程數,最大20000
MaxRequestsPerChild 4000 子進程最多能處理的請求數量。
在處理MaxRequestsPerChild 個請求以後,子進程將會被父進程終止，這時候子進程佔用的內存就會釋放(爲0時永遠不釋放）

worker
：複用的多進程I/O模型,多進程多線程，IIS使用此模型
一個主進程：生成m個子進程，每一個子進程負責生個n個線程，每一個線程響應一個請求，併發響應請求：m*n
ServerLimit 16
StartServers 2
MaxRequestWorkers 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25

event 事件驅動模型（worker模型的變種
一個主進程：生成m個子進程，每一個進程直接響應n個請求，併發響應請求：m*n，有專門的線程來管理這些keep-alive類型的線程，當有真實請求時，將請求傳遞給服務線程，執行完畢後，又容許釋放。這樣加強了高併發場景下的請求處理能力

切換mpm
cat /etc/httpd/conf.modules.d/00-mpm.conf 啓用相關的模式模塊

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0

模塊介紹：Apache 各個模塊功能 基本(B)模塊默認包含，必須明確禁用；擴展(E)/實驗(X)模塊默認不包含，必須明確啓用。
        模塊名稱    狀態    簡要描述
        mod_actions (B) 基於媒體類型或請求方法，爲執行CGI腳本而提供
        mod_alias (B) 提供從文件系統的不一樣部分到文檔樹的映射和URL重定向
        mod_asis (B) 發送本身包含HTTP頭內容的文件
        mod_auth_basic (B) 使用基本認證
        mod_authn_default (B) 在未正確配置認證模塊的狀況下簡單拒絕一切認證信息
        mod_authn_file (B) 使用純文本文件爲認證提供支持
        mod_authz_default (B) 在未正確配置受權支持模塊的狀況下簡單拒絕一切受權請求
        mod_authz_groupfile (B) 使用純文本文件爲組提供受權支持
        mod_authz_host (B) 供基於主機名、IP地址、請求特徵的訪問控制
        mod_authz_user (B) 基於每一個用戶提供受權支持
        mod_autoindex (B) 自動對目錄中的內容生成列表，相似於"ls"或"dir"命令
        mod_cgi (B) 在非線程型MPM(prefork)上提供對CGI腳本執行的支持
        mod_cgid (B) 在線程型MPM(worker)上用一個外部CGI守護進程執行CGI腳本
        mod_dir (B) 指定目錄索引文件以及爲目錄提供"尾斜槓"重定向
        mod_env (B) 容許Apache修改或清除傳送到CGI腳本和SSI頁面的環境變量
        mod_filter (B) 根據上下文實際狀況對輸出過濾器進行動態配置
        mod_imagemap (B) 處理服務器端圖像映射
        mod_include (B) 實現服務端包含文檔(SSI)處理
        mod_isapi (B) 僅限於在Windows平臺上實現ISAPI擴展
        mod_log_config (B) 容許記錄日誌和定製日誌文件格式
        mod_mime (B) 根據文件擴展名決定應答的行爲(處理器/過濾器)和內容(MIME類型/語言/字符集/編碼)
        mod_negotiation (B) 提供內容協商支持
        mod_nw_ssl (B) 僅限於在NetWare平臺上實現SSL加密支持
        mod_setenvif (B) 根據客戶端請求頭字段設置環境變量
        mod_status (B) 生成描述服務器狀態的Web頁面
        mod_userdir (B) 容許用戶從本身的主目錄中提供頁面(使用"/~username")
        mod_auth_digest (X) 使用MD5摘要認證(更安全，可是隻有最新的瀏覽器才支持)
        mod_authn_alias (E) 基於實際認證支持者建立擴展的認證支持者，併爲它起一個別名以便於引用
        mod_authn_anon (E) 提供匿名用戶認證支持
        mod_authn_dbd (E) 使用SQL數據庫爲認證提供支持
        mod_authn_dbm (E) 使用DBM數據庫爲認證提供支持
        mod_authnz_ldap (E) 容許使用一個LDAP目錄存儲用戶名和密碼數據庫來執行基本認證和受權
        mod_authz_dbm (E) 使用DBM數據庫文件爲組提供受權支持
        mod_authz_owner (E) 基於文件的全部者進行受權
        mod_cache (E) 基於URI鍵的內容動態緩衝(內存或磁盤)
        mod_cern_meta (E) 容許Apache使用CERN httpd元文件，從而能夠在發送文件時對頭進行修改
        mod_charset_lite (X) 容許對頁面進行字符集轉換
        mod_dav (E) 容許Apache提供DAV協議支持
        mod_dav_fs (E) 爲mod_dav訪問服務器上的文件系統提供支持
        mod_dav_lock (E) 爲mod_dav鎖定服務器上的文件提供支持
        mod_dbd (E) 管理SQL數據庫鏈接，爲須要數據庫功能的模塊提供支持
        mod_deflate (E) 壓縮發送給客戶端的內容
        mod_disk_cache (E) 基於磁盤的緩衝管理器
        mod_dumpio (E) 將全部I/O操做轉儲到錯誤日誌中
        mod_echo (X) 一個很簡單的協議演示模塊
        mod_example (X) 一個很簡單的Apache模塊API演示模塊
        mod_expires (E) 容許經過配置文件控制HTTP的"Expires:"和"Cache-Control:"頭內容
        mod_ext_filter (E) 使用外部程序做爲過濾器
        mod_file_cache (X) 提供文件描述符緩存支持，從而提升Apache性能
        mod_headers (E) 容許經過配置文件控制任意的HTTP請求和應答頭信息
        mod_ident (E) 實現RFC1413規定的ident查找
        mod_info (E) 生成Apache配置狀況的Web頁面
        mod_ldap (E) 爲其它LDAP模塊提供LDAP鏈接池和結果緩衝服務
        mod_log_forensic (E) 實現"對比日誌"，即在請求被處理以前和處理完成以後進行兩次記錄
        mod_logio (E) 對每一個請求的輸入/輸出字節數以及HTTP頭進行日誌記錄
        mod_mem_cache (E) 基於內存的緩衝管理器
        mod_mime_magic (E) 經過讀取部分文件內容自動猜想文件的MIME類型
        mod_proxy (E) 提供HTTP/1.1的代理/網關功能支持
        mod_proxy_ajp (E) mod_proxy的擴展，提供Apache JServ Protocol支持
        mod_proxy_balancer (E) mod_proxy的擴展，提供負載平衡支持
        mod_proxy_connect (E) mod_proxy的擴展，提供對處理HTTP CONNECT方法的支持
        mod_proxy_ftp (E) mod_proxy的FTP支持模塊
        mod_proxy_http (E) mod_proxy的HTTP支持模塊
        mod_rewrite (E) 一個基於必定規則的實時重寫URL請求的引擎
        mod_so (E) 容許運行時加載DSO模塊
        mod_speling (E) 自動糾正URL中的拼寫錯誤
        mod_ssl (E) 使用安全套接字層(SSL)和傳輸層安全(TLS)協議實現高強度加密傳輸
        mod_suexec (E) 使用與調用web服務器的用戶不一樣的用戶身份來運行CGI和SSI程序
        mod_unique_id (E) 爲每一個請求生成惟一的標識以便跟蹤
        mod_usertrack (E) 使用Session跟蹤用戶(會發送不少Cookie)，以記錄用戶的點擊流
        mod_version (E) 提供基於版本的配置段支持
        mod_vhost_alias (E) 提供大批量虛擬主機的動態配置支持
性能調優，模塊啓用/關閉
    (1)啓用壓縮
        LoadModule deflate_module modules/mod_deflate.so
    (2)啓用重寫
        LoadModule rewrite_module modules/mod_rewrite.so  
    (3)啓用默認擴展，支持在這裏進行修改httpd主要配置
        Include conf/extra/httpd-default.conf  
    (4)提供文件描述符緩存支持，從而提升Apache性能
        LoadModule file_cache_module modules/mod_file_cache.so
    (5)啓用基於URI鍵的內容動態緩衝(內存或磁盤)  
        LoadModule cache_module modules/mod_cache.so  
    (6)啓用基於磁盤的緩衝管理器
        LoadModule cache_disk_module modules/mod_cache_disk.so  
    (7)基於內存的緩衝管理器
        LoadModule socache_memcache_module modules/mod_socache_memcache.so 
    (8)屏蔽全部沒必要要的模塊
        #LoadModule authn_file_module modules/mod_authn_file.so  
        #LoadModule authn_dbm_module modules/mod_authn_dbm.so  
        #LoadModule authn_anon_module modules/mod_authn_anon.so  
        #LoadModule authn_dbd_module modules/mod_authn_dbd.so  
        #LoadModule authn_socache_module modules/mod_authn_socache.so  
        #LoadModule authn_core_module modules/mod_authn_core.so  
        #LoadModule authz_host_module modules/mod_authz_host.so  
        #LoadModule authz_groupfile_module modules/mod_authz_groupfile.so  
        #LoadModule authz_user_module modules/mod_authz_user.so  
        #LoadModule authz_dbm_module modules/mod_authz_dbm.so  
        #LoadModule authz_owner_module modules/mod_authz_owner.so  
        #LoadModule authz_dbd_module modules/mod_authz_dbd.so  
        LoadModule authz_core_module modules/mod_authz_core.so  
        LoadModule access_compat_module modules/mod_access_compat.so  
        #LoadModule auth_basic_module modules/mod_auth_basic.so  
        #LoadModule auth_form_module modules/mod_auth_form.so  
        #LoadModule auth_digest_module modules/mod_auth_digest.so 
    （9）已通過時屏蔽
        #LoadModule autoindex_module modules/mod_autoindex.so
    （10）用於定義缺省文檔index.php、index.jsp等
        LoadModule dir_module modules/mod_dir.so
    （11）用於定義記錄文件格式
        LoadModule log_config_module modules/mod_log_config.so
    （12）定義文件類型的關聯
        LoadModule mime_module modules/mod_mime.so
    （13）減小10%左右的重複請求
        LoadModule expires_module modules/mod_expires.so  
    （14）容許apache修改或清除傳遞到cgi或ssi頁面的環境變量
        LoadModule env_module modules/mod_env.so
    （15）根據客戶端請求頭字段設置環境變量，若是不須要則屏蔽掉
        #LoadModule setenvif_module modules/mod_setenvif.so
    （16）生成描述服務器狀態的頁面
        #LoadModule status_module modules/mod_status.so
    （17）別名
        LoadModule alias_module modules/mod_alias.so
    （18）url地址重寫模塊
        LoadModule rewrite_module modules/mod_rewrite.so
    （19）jk_mod 負載均衡調度模塊
        LoadModule    jk_module modules/mod_jk.so 
    （20）過濾模塊，使用緩存必須啓用過濾模塊
        LoadModule filter_module modules/mod_filter.so 
    （21）關閉服務器版本信息
        LoadModule version_module modules/mod_version.so
    （22）自動修正用戶輸入的url錯誤 
        LoadModule speling_module modules/mod_speling.so

配置虛擬機（基於Ip或端口）
/usr/share/doc/httpd-2.4.6/httpd-vhosts.conf

<VirtualHost *:@@Port@@>
ServerAdmin webmaster@dummy-host.example.com
DocumentRoot "@@ServerRoot@@/docs/dummy-host.example.com"
ServerName dummy-host.example.com
ServerAlias www.dummy-host.example.com
ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common

虛擬網站的根目錄 documentroot 若是沒有在主配置文件受權訪問，須要在虛擬配置目錄中進行受權

<VirtualHost :80> 基於域名

<VirtualHost :8080> 主配置文件須要Listen 8080

域名跳轉
目的：不帶主機名跳到www,https跳轉
1，添加虛擬機，路由重寫
<VirtualHost :80>
ServerName www.mydomain.com
ServerAlias mydomain.com
RewriteEngine On
RewriteRule ^/(.)$ https://www.mydomain.com/$1 [R=301]

DocumentRoot "/var/www/html/test"
ServerName test71.example.com
ServerAlias test71 example.com

AllowOverride AuthConfig
AuthName " haha"
AuthType Basic
AuthUserFile /var/www/html/test/.htpasswd
require valid-user

還須要 htpasswd -cm /var/www/html/test/.htpasswd redhat

網站文件壓縮

https
yum -y install mod_ssl
vim /etc/httpd/conf.d/ssl.conf
默認目錄及虛擬機目錄之間關係

自動生成CA證書腳本
rpm -q openssl &> /dev/null || yum -y install openssl
mkdir ssl && cd ssl
cat >tt <<EOF
CN
HENAN
zhengzhou
magedu
devs
www.magedu.com
admin@magedu.com
EOF

genarate CA KEY & CA cert

( umask 066;openssl genrsa 2048 > cakey.pem )
echo -e " \e[1;32m start create cakey & cacert..... \e[0m "
sleep 5
openssl req -new -x509 -key cakey.pem -out cacert.pem -days 3650 < tt
echo
echo -e "\e[1;32m start genarate httpd.key & httpd.csr...\e[0m "
sleep 5
openssl req -newkey rsa:1024 -nodes -keyout httpd.key > httpd.csr < tt
echo
echo -e "\e[1;32m genrate httpd.crt....\e[0m"
sleep 5
openssl x509 -req -in httpd.csr -CA cacert.pem -CAkey cakey.pem -set_serial 01 > httpd.crt
echo
echo -e "\e[1;32m you can check the info from use : \e[0m "
echo -e "openssl x509 -in httpd.crt -noout -text \n copy the directory to the destinary ! "

防盜鏈
1，httpd.conf
虛擬機網站配置添加重寫路由

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://maixj.net/.$ [NC]
RewriteCond %{HTTP_REFERER} !^http://maixj.net$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.maixj.net/.$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.maixj.net$ [NC]
RewriteCond %{REQUEST_URL} !^/pics/.$ [NC]
RewriteRule ..(gif|jpg|jpeg|png|bmp|mp3)$ http://www.maixj.net/pics/nolink.jpg [L,NC]
[NC] 表示not case sensitive，大小寫無關
2，.htacess

SetEnvIfNoCase 和 access 技術

http請求版本區別

http請求流程：
一次HTTP操做稱爲一個事務
大體分爲四個過程：
1，創建鏈接
在瀏覽器地址欄輸入請求資源的url後，首先會在DNS本地緩存表查找域名對應的IP，若有則直接返回,若是沒有則要求DNS進行查找，查找結束後返回給瀏覽器IP，獲取IP後，客戶端開始與服務器端經過tcp創建三次握手，鏈接成功後，開始進行下一步http請求。

DNS：首先在本地hosts文件下查找是否有域名對應的ip,如無，則在resolve.conf文件裏查找dns服務器，找到後將DNS解析請求發送給DNS服務器，由dns服務器經過遞歸及迭代查詢，並將結果返回。
網絡鏈接：客戶端根據獲取到的IP，選擇一個端口，建立一個套接字，經過OSI網絡協議尋址路由，將數據包發送到指定ip地址的機器上，若是該IP與本機IP處於同一網段，則數據直接傳送，如不在同一網段，默認將該數據包發往網關。經過三次握手創建數據鏈接通道，此時服務器端已經在指定的端口創建監聽。

2，瀏覽器向web服務器發出請求報文。
http請求報文：
一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成

1.請求行
請求行分爲三個部分：請求方法、請求地址和協議版本

請求方法

    HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

    最常的兩種GET和POST，若是是RESTful接口的話通常會用到GET、POST、DELETE、PUT。

    請求地址

    URL:統一資源定位符，是一種自願位置的抽象惟一識別方法。

    組成：<協議>：//<主機>：<端口>/<路徑>
    端口和路徑有時能夠省略（HTTP默認端口號是80）

    協議版本
    協議版本的格式爲：HTTP/主版本號.次版本號，經常使用的有HTTP/1.0和HTTP/1.1


    2.請求頭部
    請求頭部爲請求報文添加了一些附加信息，由「名/值」對組成，每行一對，名和值之間使用冒號分隔。

3.請求數據

3，web服務器解析請求，根據方法，資源，首部，和可選的主題對請求處理。對請中的靜態或動態資源處理，構建響應報文，web服務器經過鏈接響應報文，而後將訪問記錄計入日誌。
根據服務程序的響應模型，對於一個請求，服務程序又有多個不一樣的處理模型進行處理。
響應報文：

HTTP響應報文主要由狀態行、響應頭部、空行以及響應數據組成
1.狀態行
由3部分組成，分別爲：協議版本，狀態碼，狀態碼描述。

其中協議版本與請求報文一致，狀態碼描述是對狀態碼的簡單描述，因此這裏就只介紹狀態碼。

狀態碼

狀態代碼爲3位數字。
1xx：指示信息--表示請求已接收，繼續處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操做。
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現。
5xx：服務器端錯誤--服務器未能實現合法的請求

   2.響應頭部     
   3.響應數據

4，應答結束後，關閉鏈接。

通常一個請求事務結束後，關閉網絡鏈接
   TCP四次揮手
   
 tcp鏈接通常流程

http協議版本

1，http 0.9
只容許get請求，不支持請求頭，只支持純文本，迴應HTML格式字符串，
典型的無狀態，每一個事務獨立處理，處理結束後釋放鏈接，若是請求頁面不存在，不會返回任何錯誤代碼

2，http 1.0
請求與響應支持頭域
每一個鏈接爲一個事務，一個請求數據迴應後，關閉鏈接，若有其餘請求，須要新建鏈接
響應對象以一個響應狀態行開始
支持Content-Type 數據格式
響應對象不僅限於超文本
開始支持客戶端經過POST方法向Web服務器提交數據，支持GET、HEAD、POST方法
支持長鏈接（但默認仍是使用短鏈接），緩存機制，以及身份認證

3，http 1.1
引入持久鏈接,即tcp鏈接默認不關閉，能夠被多個請求複用，不用聲明keep-alive
管道機制：即在同一個TCP鏈接裏，客戶端能夠同時發送多個請求，進一步改進了HTTP協議的效率
新增方法：PUT、PATCH、OPTIONS、DELETE
同一個TCP鏈接裏，全部的數據通訊是按次序進行的。服務器只能順序處理迴應，前
面的迴應慢，會有許多請求排隊，形成"隊頭堵塞"（Head-of-line blocking）
爲避免上述問題，兩種方法：一是減小請求數，二是同時多開持久鏈接。網頁優化技
巧，如合併腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等
HTTP 協議不帶有狀態，每次請求都必須附上全部信息。請求的不少字段都是重複的，
浪費帶寬，影響速度

關鍵特性：keep-alive   chunked    字節範圍請求，請求流水線
 keep-alive  容許HTTP設備在事務處理結束以後將TCP鏈接保持在打開的狀態，一遍將來的HTTP請求重用如今的鏈接，直到客戶端或服務器端決定將其關閉爲止。
 • chunked編碼傳輸

該編碼將實體分塊傳送並逐塊標明長度,直到長度爲0塊表示傳輸結束, 這在實體長度未知時特別有用(好比由數據庫動態產生的數據)
• 字節範圍請求
HTTP1.1支持傳送內容的一部分。比方說，當客戶端已經有內容的一部分，爲了節省帶寬，能夠只向服務器請求一部分。該功能經過在請求消息中引入了range頭域來實現，它容許只請求資源的某個部分。在響應消息中Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。若是服務器相應地返回了對象所請求範圍的內容，則響應碼206（Partial Content）

請求流水線：持續發送請求，沒必要等服務器響應
新特性：
請求消息和響應消息都應支持Host頭域
在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。所以，Host頭的引入就頗有必要了。
新增了一批Request method
HTTP1.1增長了OPTIONS,PUT, DELETE, TRACE, CONNECT方法
緩存處理
HTTP/1.1在1.0的基礎上加入了一些cache的新特性，引入了實體標籤，通常被稱爲e-tags，新增更爲強大的Cache-Control頭。

4，http2.0

頭信息和數據體都是二進制，稱爲頭信息幀和數據幀
複用 tcp鏈接：在一個鏈接裏，客戶端和瀏覽器均可以同時發送多個請求或迴應，且不用按順序一一對應，避免了「隊頭堵塞「,此雙向的實時通訊稱爲多工（Multiplexing）
引入頭信息壓縮機制（header compression）,頭信息使用gzip或compress
壓縮後再發送；客戶端和服務器同時維護一張頭信息表，全部字段都會存入
這個表，生成一個索引號，不發送一樣字段，只發送索引號，提升速度
HTTP/2 容許服務器未經請求，主動向客戶端發送資源，即服務器推送
（server push）

多路複用（二進制分幀）
HTTP 2.0最大的特色: 不會改動HTTP 的語義，HTTP 方法、狀態碼、URI 及首部字段，等等這些核心概念上一如往常，卻能致力於突破上一代標準的性能限制，改進傳輸性能，實現低延遲和高吞吐量。而之因此叫2.0，是在於新增的二進制分幀層。在二進制分幀層上， HTTP 2.0 會將全部傳輸的信息分割爲更小的消息和幀,並對它們採用二進制格式的編碼，其中HTTP1.x的首部信息會被封裝到Headers幀，而咱們的request body則封裝到Data幀裏面
頭部壓縮
當一個客戶端向相同服務器請求許多資源時，像來自同一個網頁的圖像，將會有大量的請求看上去幾乎一樣的，這就須要壓縮技術對付這種幾乎相同的信息。
隨時復位
HTTP1.1一個缺點是當HTTP信息有必定長度大小數據傳輸時，你不能方便地隨時中止它，中斷TCP鏈接的代價是昂貴的。使用HTTP2的RST_STREAM將能方便中止一個信息傳輸，啓動新的信息，在不中斷鏈接的狀況下提升帶寬利用效率。
服務器端推流: Server Push
客戶端請求一個資源X，服務器端判斷也許客戶端還須要資源Z，在無需事先詢問客戶端狀況下將資源Z推送到客戶端，客戶端接受到後，能夠緩存起來以備後用。
優先權和依賴
每一個流都有本身的優先級別，會代表哪一個流是最重要的，客戶端會指定哪一個流是最重要的，有一些依賴參數，這樣一個流能夠依賴另一個流。優先級別能夠在運行時動態改變，當用戶滾動頁面時，能夠告訴瀏覽器哪一個圖像是最重要的，你也能夠在一組流中進行優先篩選，可以忽然抓住重點流。

HTTP1.0和HTTP1.1的區別

 緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標
準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match,
If-None-Match等更多可供選擇的緩存頭來控制緩存策略
 帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某
個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在
請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），
方便了開發者自由的選擇以便於充分利用帶寬和鏈接
 錯誤通知的管理，在HTTP1.1中新增24個狀態響應碼，如409（Conflict）表示請求的資源與資
源當前狀態衝突；410（Gone）表示服務器上的某個資源被永久性的刪除
 Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的
URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠
存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請
求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400
Bad Request）
 長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，
在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在
HTTP1.1中默認開啓Connection： keep-alive，彌補了HTTP1.0每次請求都要建立鏈接的缺點
HTTP1.x在傳輸數據時，每次都須要從新創建鏈接，無疑增長了大量的延遲時
間，特別是在移動端更爲突出
HTTP1.x在傳輸數據時，全部傳輸的內容都是明文，客戶端和服務器端都沒法
驗證對方的身份，沒法保證數據的安全性
 HTTP1.x在使用時，header裏攜帶的內容過大，增長了傳輸的成本，而且每次
請求header基本不怎麼變化，尤爲在移動端增長用戶流量
 雖然HTTP1.x支持了keep-alive，來彌補屢次建立鏈接產生的延遲，可是keepalive使用多了一樣會給服務端帶來大量的性能壓力，而且對於單個文件被不斷
請求的服務(例如圖片存放網站)，keep-alive可能會極大的影響性能，由於它在
文件被請求以後還保持了沒必要要的鏈接很長時間

獲取網頁的方式（事務）
串行依次三次握手獲取資源四次揮手（一個進程）
並行並行三次握手獲取資源四次回收（並行多個進程）

串行持久鏈接：一次鏈接多個請求
管道化持久：

http版本特性區別
web服務器請求處理步驟
web訪問響應模型

2.4默認支持持久鏈接
測試持久鏈接：
telnet

長短鏈接根據業務場景

2.4
文件夾須要受權才能訪問

文件共享 index
已受權目錄
options +-

welcome 配置文件更名

測試全局或在某個目錄下
瀏覽器有緩存，強制刷新 CTRL+ f5
虛擬機配置內重定向(a--->b)
redirect tmp / http://xxx.xxxx.com

a>>>>https
https://

報錯：重頂向次數太多
使用 rewriterule 進行重定向

sendfile
通常文件在本機能夠啓用sendfile

apache 反向代理

訪問量

IP(獨立IP)：即Internet Protocol,指獨立IP數。一天內來自相同客戶機IP地址只計算一次，記錄遠程客戶機IP地址的計算機訪問網站的次數，是衡量網站流量的重要指標.
PV(訪問量)：即Page View, 頁面瀏覽量或點擊量，用戶每次刷新即被計算一次，PV反映的是瀏覽某網站的頁面數，PV與來訪者的數量成正比，PV並非頁面的來訪者數量，而是網站被訪問的頁面數量
UV(獨立訪客)：即Unique Visitor,訪問網站的一臺電腦爲一個訪客。一天內相同的客戶端只被計算一次。能夠理解成訪問某網站的電腦的數量。網站判斷來訪電腦的身份是經過來訪電腦的cookies實現的。若是更換了IP後但不清除cookies，再訪問相同網站，該網站的統計中UV數是不變的。

QPS：request per second，每秒請求數
PV，QPS,併發鏈接數換算公式
QPS= PV* 頁面衍生鏈接次數/ 統計時間（86400）
併發鏈接數 =QPS * http平均響應時間

峯值時間：天天80%的訪問集中在20%的時間裏，這20%時間爲峯值時間
峯值時間每秒請求數(QPS)=( 總PV數 *頁面衍生鏈接次數）*80% ) / ( 天天秒數* 20% )


建設一個能承受500萬PV/天天的網站嗎？ 500萬PV是什麼概念？服務器每秒要處理多少個請求才能應對？若是計算呢
計算模型：
每臺服務器每秒處理請求的數量=((80%*總PV量)/(24小時*60分*60秒*40%)) / 服務器數量 。
其中關鍵的參數是80%、40%。表示一天中有80%的請求發生在一天的40%的時間內。24小時的40%是9.6小時，有80%的請求發生一天的9.6個小時當中（很適合互聯網的應用，白天請求多，晚上請求少）

簡單計算的結果：

((80%500萬)/(24小時60分60秒40%))/1 = 115.7個請求/秒
((80%100萬)/(24小時60分60秒40%))/1 = 23.1個請求/秒

初步結論：
如今咱們在作壓力測試時，就有了標準，若是你的服務器一秒能處理115.7個請求，就能夠承受500萬PV/天天。若是你的服務器一秒能處理23.1個請求，就能夠承受100萬PV/天天

留足餘量：

以上請求數量是均勻的分佈在白天的9.6個小時中，但實際狀況並不會這麼均勻的分佈，會有高峯有低谷。爲了應對高峯時段，應該留一些餘地，最少也要x2倍，x3倍也不爲過。

115.7個請求/秒 *2倍=231.4個請求/秒

115.7個請求/秒 *3倍=347.1個請求/秒

23.1個請求/秒 *2倍=46.2個請求/秒

23.1個請求/秒 *3倍=69.3個請求/秒

最終結論：

若是你的服務器一秒能處理231.4--347.1個請求/秒，就能夠應對平均500萬PV/天天。

若是你的服務器一秒能處理46.2--69.3個請求，就能夠應對平均100萬PV/天天。
說明：
這裏說明每秒N個請求，就是QPS。由於我關心的是應用程序處理業務的能力。

實際經驗：

一、根據實際經驗，採用兩臺常規配置的機架式服務器，配置是很常見的配置，例如一個4核CPU+4G內存+服務器SAS硬盤。

二、我的武斷的認爲在服務器CPU領域Intel的CPU要優於AMD的CPU，有反對的就反對吧，我都說我武斷了（請看CPU性能比較），不要太相信AMD的廣告，比較CPU性能簡單辦法就是比價格，不要比頻率與核心數，價格相差很少的性能也相差很少。

三、硬盤的性能很重要，由其是數據庫服務器。通常的服務器都配1.5萬轉的SAS硬盤，高級一點的能夠配SSD固態硬盤，性能會更好。最最最最重要的指標是「隨機讀寫性能」而不是「順序讀寫性能」。（本例仍是配置最多見的1.5萬轉的SAS硬盤吧）

四、一臺服務器跑Tomcat運行j2ee程序,一臺服務器跑MySql數據庫,程序寫的中等水平(這個真的很差量化)，是論壇類型的應用(總有回帖,不太容易作緩存,也沒法靜態化)。

五、以上軟硬件狀況下，是能夠承受100萬PV/天天的。(已留有餘量應對忽然的訪問高峯)

注意機房的網絡帶寬：

有人說以上條件我都知足了，但實際性能仍是達不到目標。這時請注意你對外的網絡的帶寬，在國內服務器便宜但帶寬很貴，極可能你在機房是與你們共享一條100M的光纖，實際每一個人可分到2M左右帶寬。再好一點5M,再好一點雙線機房10M獨享，這已經很貴了（北京價格）。

一天總流量：每一個頁面20k字節*100萬個頁面/1024=19531M字節=19G字節，

19531M/9.6小時=2034M/小時=578K字節/s 若是請求是均勻分佈的，須要5M（640K字節）帶寬（5Mb=640KB 注意大小寫，b是位，B是字節，差了8倍），但全部請求不多是均勻分佈的，當有高峯時5M帶寬必定不夠，X2倍就是10M帶寬。10M帶寬基本能夠知足要求。

以上是假設每一個頁面20k字節，基本不包含圖片，要是包含圖片就更大了，10M帶寬也不能知足要求了。你自已計算吧。

性能測試基本概念
---------------------------------------------------------------------------------------
基本概念：
Throughput（吞吐量）：按照常規理解網絡吞吐量表示在單位時間內經過網卡數據量之和，其中即包括本機網卡發送出去的數據量也包括本機網卡接收到的數據量。一個100Mb(位)的雙工網卡，最大發送數據的速度是12.5M字節/s ，最大接收數據的速度是12.5M字節/s，能夠同時收發數據。
併發用戶數：是同時執行操做的用戶(線程數)。
響應時間：從請求發出到收到響應花費的時間。

QPS - Queries Per Second 每秒處理的查詢數（若是是數據庫，就至關於讀取）
TPS - Transactions Per Second 每秒處理的事務數(若是是數據庫，就至關於寫入、修改)
IOPS，每秒磁盤進行的I/O操做次數

例如對某個數據庫測試，分開兩次測QPS與TPS。
QPS（讀取）值老是高於TPS(寫、改)，而且有倍率關係，由於：
一、數據庫對查詢可能有緩存。
二、機械硬盤或SSD硬盤的讀就是比寫快。

PV=page view
TPS=transactions per second
QPS=queries per second
RPS=requests per second
RPS=併發數/平均響應時間

一個小例子：
一個典型的上班簽到系統，早上8點上班。7點半到8點這30分鐘的時間裏用戶會登陸簽到系統進行簽到。公司員工爲1000人，平均每個員上登陸簽到系統的時長爲5分鐘。可以用如下的方法計算。
QPS = 1000/(3060) 事務/秒
平均響應時間爲 = 560 秒
併發數= QPS平均響應時間 = 1000/(3060) (560)=166.7

通常衡量網站性能有哪些指標？
性能指標主要有響應時間，吞吐量，併發量，性能計數器。
1）響應時間指應用執行一個操做須要的時間，即從發出請求到最後收到響應數據所須要的時間。

系統經常使用操做響應時間表

實踐中一般採用的辦法是重複請求，好比一個請求操做重複執行1萬次，測試一萬次執行的總響應時間之和，而後除以1萬，就獲得單次請求的響應時間
2）吞吐量
指單位時間內系統處理的請求數量，體現系統的總體處理能力。對於網站，可用「請求數/秒」、「頁面數/秒」或「訪問人數/天」、「處理業務數/小時」等來衡量。重要指標有TPS(每秒處理的事物數)、QPS(每秒查詢的請求數)、HPS（每秒HTTP請求數）等。
3）併發量
指系統可以同時處理的請求的數目，這個數字反映了系統的負載性能。對於網站而言，併發數指網站用戶同時提交請求的用戶數目。
4）性能計數器
描述服務器或操做系統性能的一些數據指標。如System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡I/O等使用狀況。經過對這些指標設置報警閾值，當監控系統發現性能計數器超過閾值時，就向開發人員和運維報警，及時發現異常並處理。

怎麼測試網站性能？
性能測試具體能夠細分爲性能測試、負載測試、壓力測試、穩定性測試。
1）性能測試
以系統設計初期規劃的性能指標爲預期目標，對系統不斷施加壓力，驗證系統在資源可接受範圍內是否能達到預期。
2）負載測試
對系統不斷增長併發請求以增長系統壓力，直到系統的某項或多項性能指標達到安全臨界值，這時繼續對系統施加壓力，系統的處理能力不但不會提升，反而會降低。
3）壓力測試
超過安全負載的狀況下，對系統施加壓力，直到系統崩潰或不能再處理任何請求，以此得到系統最大壓力承受能力。
4）穩定性測試
被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載必定業務壓力，使系統運行一段較長時間，以此檢驗系統是否穩定。

壓力測試工具備http_load、apache ab、siege。
1）http_load
http_load -p 併發訪問進程數 -f 訪問總數須要訪問的URL文件
http_load -r 每秒訪問頻率 -s 訪問時間須要訪問的URL文件
// 參數說明：一般參數pf一塊兒使用，參數rs一塊兒使用。
-parallel 簡寫 -p ：併發的用戶進程數。
-fetches 簡寫 -f ：總計的訪問次數。
-rate 簡寫 -r ：每秒的訪問頻率。
-seconds 簡寫 -s ：總計的訪問時間。

新建一個urls.txt，urls.txt 是一個url 列表，每一個url 單獨的一行。
在文件中加入一行：http://www.acme.com/software/http_load/
① 測試網站是否能承受住預期的訪問壓力
執行http_load -rate 5 -seconds 10 urls.txt，含義爲在10秒內保持必定的頻率訪問目標url。

反饋分析
fetches, 6 max parallel, 253264 bytes, in 10.0031 seconds
// 說明在上面的測試中運行了48個請求，最大的併發進程數是6，總計傳輸的數據是253264bytes，運行的時間是10.0031秒
5276.33 mean bytes/connection
// 說明每次鏈接平均傳輸的數據量是5276.33bytes。253264/48=5276.33
4.7985 fetches/sec, 25318.5 bytes/sec
// 說明每秒的響應請求爲4.7985個，每秒傳遞的數據爲25318.5 bytes
msecs/connect: 251.601 mean, 1493.45 max, 26.176 min
// 說明每次鏈接的平均響應時間是251.601 毫秒，最大的響應時間1493.45 毫秒，最小的響應時間26.176 毫秒
msecs/first-response: 232.251 mean, 796.783 max, 39.402 min
// 說明每次鏈接的平均返回時間是232.251 毫秒，最大的響應時間796.783 毫秒，最小的響應時間39.402 毫秒
HTTP response codes:
code 200 -- 48
// 說明HTTP返回碼是200，一共48次。

主要參考fetches/sec、msecs/connect數值，
前者對應QPS，表示每秒的響應請求數，後者對應response time，表示每一個鏈接的響應時間。

② 測試網站每秒所能承受的平均訪問量
執行http_load -parallel 5 -fetches 1000 urls.txt，含義爲同時使用5個進程，隨機訪問urls.txt中的網址列表，總共訪問1000次。

fetches, 5 max parallel, 2。607e+06 bytes, in 328.806 seconds
mean bytes/connection
3.04131 fetches/sec, 7928.69 bytes/sec
msecs/connect: 772.326 mean, 19478.3 max, 219.936 min
msecs/first-response: 830.46 mean, 10006.4 max, 237.957 min
HTTP response codes:
code 200 — 1000

從上面結果看，目標網站僅僅可以承受每秒3次的訪問，不夠強壯。

2）apache ab

ab -c 併發數 -n 請求數 URL
// 參數說明：
-n 在測試會話中所執行的請求個數。默認時，僅執行一個請求
-c 一次產生的請求個數。默認是一次一個。
-t 測試所進行的最大秒數。其內部隱含值是-n 50000。它可使對服務器的測試限制在一個固定的總時間之內。默認時，沒有時間限制。

執行ab -n 100 -c 100 http://127.0.0.1/test/test.php，含義爲同時處理100個請求並運行100次test.php，模擬100個併發用戶，對一個頁面發送100個請求。

Server Software: Apache/2.4.23 // 服務器名稱，apache 版本2.4.23
Server Hostname: 127.0.0.1 // 服務器主機名
Server Port: 80 // 服務器端口

Document Path: /test/test.php // 請求的URL中的根絕對路徑，經過該文件的後綴名，咱們通常能夠了解該請求的類型
Document Length: 54 bytes // HTTP響應數據的正文長度

Concurrency Level: 100 // 併發用戶數
Time taken for tests: 0.085 seconds // 整個測試持續的時間，全部這些請求被處理完成所花費的總時間
Complete requests: 100 // 完成的請求數量
Failed requests: 0 // 失敗的請求數量
Total transferred: 25600 bytes // 全部請求的響應數據長度總和，包括每一個HTTP響應數據的頭信息和正文數據的長度
HTML transferred: 5400 bytes // 全部請求的響應數據中正文數據的總和，也就是減去了Total transferred中HTTP響應數據中的頭信息的長度。
Requests per second: 1177.59 [#/sec] (mean) // 吞吐率，計算公式：Complete requests/Time taken for tests。至關於每秒事務數，後面括號中的 mean 表示這是一個平均值。吞吐率越高，服務器性能越好。
Time per request: 84.919 [ms] (mean) // 用戶平均請求等待時間，計算公式：Time token for tests/（Complete requests/Concurrency Level）。至關於平均事務響應時間，後面括號中的 mean 表示這是一個平均值。
Time per request: 0.849 [ms] (mean, across all concurrent requests) // 服務器平均請求等待時間，計算公式：Time taken for tests/Complete requests，正好是吞吐率的倒數。也能夠這麼統計：Time per request/Concurrency Level。
Transfer rate: 294.40 [Kbytes/sec] received //這些請求在單位時間內從服務器獲取的數據長度，即平均每秒網絡上的流量，計算公式：Total trnasferred/ Time taken for tests，這個統計很好的說明服務器的處理能力達到極限時，其出口寬帶的需求量，能夠幫助排除是否存在網絡流量過大致使響應時間延長的問題。

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.4 2 3
Processing: 6 44 23.4 46 81
Waiting: 6 44 23.5 46 81
Total: 8 46 23.1 47 82
// 網絡上消耗的時間的分解
Percentage of the requests served within a certain time (ms)
50% 47
66% 60
75% 66
80% 72
90% 76
95% 80
98% 82
99% 82
100% 82 (longest request)
// 這部分數據用於描述每一個請求處理時間的分佈狀況，好比以上測試，66%的請求處理時間都不超過60ms，這個處理時間是指前面的Time per request，即對於單個用戶而言，平均每一個請求的處理時間。

系統性能指標
https://www.cnblogs.com/sunshineliulu/p/7516034.html

1、經典公式1：
   通常來講，利用如下經驗公式進行估算系統的平均併發用戶數和峯值數據

1）平均併發用戶數爲 C = nL/T
2）併發用戶數峯值 C‘ = C + 3根號C
    C是平均併發用戶數，n是login session的數量，L是login session的平均長度，T是值考察的時間長度
    C’是併發用戶數峯值

  舉例1，假設系統A，該系統有3000個用戶，平均天天大概有400個用戶要訪問該系統（能夠從系統日誌從得到），對於一個典型用戶來講，一天以內用戶從登錄到退出的平均時間爲4小時，而在一天以內，用戶只有在8小時以內會使用該系統。
那麼，
  平均併發用戶數爲：C = 4004/8 = 200
  併發用戶數峯值爲：C‘ = 200 + 3*根號200 = 243

舉例2，某公司爲其170000名員工設計了一個薪酬系統，員工可進入該系統查詢本身的薪酬信息，但並非每一個人都會用這個系統，假設只有50%的人會按期用該系統，這些人裏面有70%是在每月的最後一週使用一次該系統，且平均使用系統時間爲5分鐘。
則一個月最後一週的平均併發用戶數爲（朝九晚五）：
n = 1700000.50.7/5 = 11900
C= 119005/60/8 = 124

吞吐量計算爲：F = Vu R / T 單位爲個/s
F爲事務吞吐量，Vu爲虛擬用戶數個數，R爲每一個虛擬用戶發出的請求數，T爲處理這些請求所花費的時間

2、通用公式2：
對絕大多數場景，咱們用（用戶總量/統計時間）影響因子（通常爲3）來進行估算併發量。
好比，以乘坐地鐵爲例子，天天乘坐人數爲5萬人次，天天早高峯是7到9點，晚高峯是6到7點，根據8/2原則，80%的乘客會在高峯期間乘坐地鐵，則每秒到達地鐵檢票口的人數爲5000080%/（36060）=3.7，約4人/S，考慮到安檢，入口關閉等因素，實際堆積在檢票口的人數確定比這個要大，假定每一個人須要3秒才能進站，那實際併發應爲4人/s3s=12，固然影響因子能夠根據實際狀況增大！

3、根據PV計算公式：
好比一個網站，天天的PV大概1000w，根據2/8原則，咱們能夠認爲這1000w pv的80%是在一天的9個小時內完成的（人的精力有限），那麼TPS爲：
1000w80%/(93600)=246.92個/s,取經驗因子3，則併發量應爲：
246.923=740

4、根據TPS估計：
公式爲 C = (Think time + 1)*TPS

5、根據系統用戶數計算：
併發用戶數 = 系統最大在線用戶數的8%到12%
備註：本人目前在網上只找到了這5種，計算併發用戶數的方法，其餘計算方法，歡迎你們留言補充

1.業務併發用戶數；2.最大併發訪問數；3.系統用戶數；4.同時在線用戶數；
假設一個OA系統有1000用戶，這是系統用戶數；最高峯同時有500人在線，是「同時在線人數」，也稱做「最大業務併發用戶數」；500個同時使用系統用戶中20%查看系統公告，不構成壓力；20%填寫表格（只在提交時纔會請求，填寫對服務器不構成壓力）；40%在發呆（什麼都沒作）；20%用戶不停從一個頁面跳轉另外一個頁面（只有這20%對服務器產生了壓力）。
說明服務器實際壓力，能承受的最大併發訪問數，既取決於業務併發用戶數，還取決於用戶的業務場景，這些能夠經過對服務器日誌的分析獲得。
通常只須要分析出典型業務（用戶經常使用，最關注的業務操做）
給出一個估算業務併發用戶數的公式（測試人員通常只關心業務併發用戶數）
C=nL/T
C^=C+3×(C的平方根)
C是平均的業務併發用戶數、n是login session的數量、L是login session的平均長度、T是指考察的時間段長度、C^是指業務併發用戶數的峯值。
該公式的得出是假設用戶的login session產生符合泊松分佈而估算獲得。
假設OA系統有1000用戶，天天400個用戶發訪問，每一個登陸到退出平均時間2小時，在1天時間內用戶只在8小時內使用該系統。
C=400×2/8=100
C^=100+3×(100的平方根)=100+3×10=130
另外，若是知道平均每一個用戶發出的請求數u，則系統吞吐量能夠估算爲u×C
請注意：精確估算，還要考慮用戶業務操做存在必定的時間集中性（好比上班後1小時內是OA系統高峯期），採用公式計算仍然會存在誤差。針對例子OA系統能夠把1小時設定爲考察時間的粒度，將一天8小時劃分爲8個區間，這樣能夠解決業務操做存在集中性問題，更趨於精準，誤差更小。

若每個月有30000次的用戶登陸系統，天天8小時工做日，每個月80%的登陸在20%的時間內完成，天天80%的業務在20%的時間內完成，計算每分鐘併發量的最大值和最小值（提示：併發用戶最大值按日高峯訪問量的80%同時訪問計算，併發用戶量最小值按照日均訪問量的80%計算）

解答：

提醒：首先容易出錯的在於每個月、天天這兩個詞，必定要注意

1.每個月80%的登陸在20%的時間內完成

月總登陸次數：30000次；30000*80%=24000

每個月按30日計算（這裏須要注意點，題目並無說按工做日算，暫且按30日算）：30*20%=6

獲得日高峯登陸系統次數：24000/6=4000次

2.天天80%的業務在20%的時間內完成

每日平均登陸次數（按30天計算）：30000/30=1000次

天天80%的業務次數：1000*80%=800次

天天8小時計算，20%時間完成：8*20%=1.6小時

每分鐘的登陸次數：800/（1.6*60）=8.3次

3.提示：併發用戶最大值按日高峯訪問量的80%同時訪問計算，併發用戶量最小值按照日均訪問量的80%計算

（1）併發用戶最大值按日高峯訪問量的80%同時訪問計算

日高峯訪問量80%：4000*80%=3200次

每分鐘最大併發數：3200/（1.6*60）=33.33次

（2）併發用戶量最小值按照日均訪問量的80%計算

每分鐘最小併發數：800/（1.6*60）=8.3次

一個系統的最大併發用戶數爲1100，怎麼能推算出該系統的支持最大用戶數。
其中用戶性能要求以下：支持100萬註冊用戶性能需求分析：
一、根據用戶的要求，本系統要支持100萬用戶，其中性能機器配置如何？高峯值是多少？帶寬？等
二、若是都是採用公司的測試環境，那麼本次性能應該作哪幾種性能？性能評測、負載測試、強度測試？
三、怎麼算出併發用戶數？響應時間？性能指標
肯定：由於用戶的性能需求太廣，沒有定到具體的數值。
那麼我怎麼開展後繼的工做？
一、肯定採用公司測試環境，不用考慮環境問題。也就是說，客戶端、服務端以及帶寬等一系統均可以不用考慮，這是固定。
二、考慮此項目組之前開發過的系統性能狀況，可否作爲一個參考值。
解決方案：找出本項目組以併發過二個項目，其性能個項指標進行求權。
其中瀏覽功能：併發數爲1100，平均響應時間363秒；每用戶平均響應時間爲0.33秒。每秒中併發3個用戶。其中一系統用戶已達500萬，另外一系統用戶爲320萬。而且二系統一直運行正常，但目前的二系統的服務器各爲3臺。能夠得出一臺服務器爲載166萬，甚至更多。（由於服務器中有求權的關係）三、100萬用戶，那麼怎麼計算出他的每小時峯值活動用戶數？解決方案：採用80•20原則計算獲得每小時峯值活動用戶數 6.667萬/小時；那麼每秒中的同一功能點點擊併發數應該是18.5。四、怎麼得其併發數？解決方案：本系統有多少個功能點？功能點爲153個；也就是本系統在高峯值時一功能將被點擊1258次，每秒點擊0.35次。（不考慮間隔時間）考慮之前本項目組的數值。初步設置併發數爲1100，主要以瀏覽功能爲主、其次是查詢和新增。五、應該測試那種性能類型經再三考慮，三種性能都進行測試。執行性能：評測，依據性能指標肯定中的第三點，將用戶的併發設置爲300-350，看其狀況。負載測試，以1100爲起點強度測試，爲15小時和24小時爲準性能測試結果：發現本系統最大用戶支持爲1100.失敗用戶最高爲209，響應時間爲315。能夠判斷此係統最大併發數爲1100左右。也就說此係統在一臺服務器上可支持150萬用戶數。根據上述狀況，能夠得出：1100用戶併發時，用戶一共響應時間爲315秒（即每用戶平均響應時間0.005秒），其中最高產生209個失敗用戶，但成功用戶基本上能夠完成後續操做，符合現系統要求的最大穩定用戶數。由此可得出本系統在新增功能點中支持最大用戶併發數爲1100。按照1*100比例，計算獲得每小時峯值活動用戶數11萬/小時；採用80•20原則計算得出本系統支持註冊用戶數約爲165萬。而本系統性能需求大規模支持100萬註冊用戶，由上述的數據咱們的系統已達到本系統性能需求。注：100萬，採用80•20原則計算獲得每小時峯值活動用戶數6.667萬/小時。

編譯腳本

echo "create datadir..."
mkdir /htdata  &&  cd   /htdata
echo "install gcc pcre-devel opsenssl......"
sleep  5
yum install gcc pcre-devel openssl-devel expat-devel autoconf libtool gcc-c++
echo "wget httpd apr  apr-tuil...."
sleep  5
wget  http://mirrors.tuna.tsinghua.edu.cn/apache//httpd/httpd-2.4.39.tar.gz
wget http://mirrors.tuna.tsinghua.edu.cn/apache//apr/apr-1.7.0.tar.gz
wget http://mirrors.tuna.tsinghua.edu.cn/apache//apr/apr-util-1.6.1.tar.gz
echo "uncompress....."
ls  /htdata  | awk '{print "tar xf " $1 }' | bash 
echo "copy  pre datadir to  httpd dir..."
sleep  5
cp -r apr-1.7.0 httpd-2.4.39/srclib/apr
cp -r apr-util-1.6.1 httpd-2.4.39/srclib/apr-util
cd httpd-2.4.39/
echo "./configure  ....."
./configure --prefix=/app/httpd24 --enable-so --enable-ssl --enable-cgi --enable-rewrite --with-zlib --with-pcre --with-included-apr --enable-modules=most --enable-mpms-shared=all --with-mpm=prefork    
echo "make && install"
sleep  5
make &&  make install
echo "add  PATH"
echo 'PATH=/app/httpd24/bin:$PATH'  > /etc/profile.d/httpd24.sh
useradd -r -s /sbin/nologin apache
echo -e  "User apache \n Group apache \n"  > /app/httpd24/conf/httpd.conf
echo '/app/httpd24/bin/apachectl start'  >> /etc/rc.d/rc.local
chmod +x /etc/rc.d/rc.local
echo   "start & reboot "
sleep  5
apachectl start 
reboot

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。