起因：線上的一臺伺服器，最近總是出現 訪問 很慢的情況發生，點選一個連結要2秒鐘以上才能開啟，按照我們對於訪問人數的估計，伺服器應該不至於響應這麼慢，從而需要針對這個問題進行分析，來解決網站訪問過慢。

分析：

1、首先，在頁面訪問變慢情況發生時，使用 top 命令查看了伺服器的負載情況，發現負載並不高，初步估計不是程式的問題。
2、然後，查看了執行緒中的 httpd 的數量， ps -aux | grep httpd | wc -l 發現，執行緒數已經達到了 apache 設定的最大值。由此斷定是網站訪問人數過多造成了訪問過慢。
3、為了驗證，查看了連線數和當前的連線數，分別是
    netstat -ant | grep $ip:80 | wc -l
    netstat -ant | grep $ip:80 | grep EST | wc -l
    發現果然，連線數特別多，遠遠超過我們的估計值。
4、剛開始的時候，對於伺服器的 MPM 配置方式不是特別的熟悉，認為修改伺服器配置可以解決問題。主要的配置部分包括 prefork 模式 或者 work 模式的配置，下面是一些簡單的介紹。

    prefork 模式：
    以 prefork 模式工作的 apache 的預設配置：
    <IfModule mpm_prefork_module>
        ServerLimit             2000   
        StartServers               5    #指定伺服器啟動時建立的子程序數量
        MinSpareServers            5    #指定空閒子程序的最小數量
        MaxSpareServers           10    #指定空閒子程序的最大數量
        MaxClients               150    #指定同一時間客戶端最大接入請求的數量（單個程序併發執行緒數），任何超過該限制的請求都將進入等候佇列，一旦一個連線被釋放，佇列中的請求將得到服務
        MaxRequestsPerChild        0    #指定每個子程序在其生存週期內允許伺服的最大請求數量，預設為10000，0表示子程序永遠不結束
    </IfModule>
    prefork 控制程序在最初建立“StartServers”個子程序後，為了滿足 MinSpareServers 設定的需要建立一個程序，等待一秒鐘，繼續建立兩個，再等待一秒鐘，繼續建立四個……如此按指數級增加建立的程序數，最多達到每秒32個，直到滿足MinSpareServers設定的值為止。這種模式可以不必在請求到來時再產生新的程序，從而減小了系統開銷以增加效能。
    MaxSpareServers 設定了最大的空閒程序數，如果空閒程序數大於這個值，Apache會自動kill掉一些多餘程序。這個值不要設得過大，但如果設的值比 MinSpareServers小，Apache會自動把其調整為 MinSpareServers+1。如果站點負載較大，可考慮同時加大MinSpareServers和MaxSpareServers。
    MaxClients是這些指令中最為重要的一個，設定的是 Apache可以同時處理的請求，是對Apache效能影響最大的引數。其預設值150是遠遠不夠的，如果請求總數已達到這個值（可通過ps -ef|grep httpd|wc -l來確認），那麼後面的請求就要排隊，直到某個已處理請求完畢。這就是系統資源還剩下很多而HTTP訪問卻很慢的主要原因。雖然理論上這個值越大，可以處理的請求就越多，但Apache預設的限制不能大於256。在 apache2 中通過ServerLimit指令無須重編譯Apache就可以加大MaxClients。
    雖然通過設定ServerLimit，我們可以把MaxClients加得很大，但是往往會適得其反，系統耗光所有記憶體。以一臺伺服器為例：記憶體2G，每個apache程序消耗大約0.5%（可通過ps aux來確認）的記憶體，也就是10M，這樣，理論上這臺伺服器最多跑200個apache程序就會耗光系統所有記憶體，所以，設定MaxClients要慎重。
    worker 模式：
    以 worker 模式工作的 apache 的預設配置為：
    <IfModule mpm_worker_module>
        StartServers               2
        MaxClients               150
        MinSpareThreads           25
        MaxSpareThreads           75
        ThreadsPerChild           25
        MaxRequestsPerChild        0
    </IfModule>
    Worker 由主控制程序生成“StartServers”個子程序，每個子程序中包含固定的ThreadsPerChild執行緒數，各個執行緒獨立地處理請求。同樣，為了不在請求到來時再生成執行緒，
    MinSpareThreads和MaxSpareThreads設定了最少和最多的空閒執行緒數；而MaxClients 設定了同時連入的clients最大總數。如果現有子程序中的執行緒總數不能滿足負載，控制程序將派生新的子程序。
    MinSpareThreads和 MaxSpareThreads的最大預設值分別是75和250。這兩個引數對Apache的效能影響並不大，可以按照實際情況相應調節。
    ThreadsPerChild是worker MPM中與效能相關最密切的指令。
    ThreadsPerChild的最大預設值是64，如果負載較大，64也是不夠的。這時要顯式使用 ThreadLimit指令，它的最大預設值是20000。
    Worker模式下所能同時處理的請求總數是由子程序總數乘以ThreadsPerChild 值決定的，應該大於等於MaxClients。如果負載很大，現有的子程序數不能滿足時，控制程序會派生新的子程序。預設最大的子程序總數是16，加大時也需要顯式宣告ServerLimit（最大值是20000）。需要注意的是，如果顯式聲明瞭ServerLimit，那麼它乘以 ThreadsPerChild的值必須大於等於MaxClients，而且MaxClients必須是ThreadsPerChild的整數倍，否則 Apache將會自動調節到一個相應值。

    伺服器的apache採用的是 prefork 的工作模式，對 MaxClients 進行了相應的調整，發現服務啟動後很短時間，連線數就能夠達到最大。
5、後來想到需要檢視使用者都是訪問的那些頁面，將配置中的 access_log 開啟，發現85%以上的訪問都是直接訪問的資原始檔，由此判定，使用者可能使用了多執行緒的下載工具，或者這些資源遭受了盜鏈。
6、找到了問題所在，進行解決也就比較好辦了。想到了兩個方法：
    A、對單個IP進行連線的執行緒限制，不允許多執行緒連線資源。
        對於IP限制，我採用了 mod_limitipconn 這個模組。這個模組的好處是比較簡單，缺點是不能夠針對單獨的資料夾或者檔案進行設定，而且不支援虛擬主機。
        在 apache 中安裝了這個模組後，在配置檔案中新增如下幾段就可以生效了：
            ExtendedStatus On
            < IfModule mod_limitipconn.c >
                < Location / >   # 所有虛擬主機的/目錄
                    MaxConnPerIP 3     # 每IP只允許3個併發連線
                    NoIPLimit image/* # 對圖片不做IP限制
                < /Location >
            < Location /mp3 > # 所有主機的/mp3目錄
            MaxConnPerIP 1         # 每IP只允許一個連線請求   
            OnlyIPLimit audio/mpeg video    # 該限制只對視訊和音訊格式的檔案
                < /Location >
            < /IfModule >
    B、新增URL重寫，防止盜鏈。
        防止盜鏈，一個重要的方法就是判斷請求的 refer，但是如果使用一些瀏覽器發出請求的時候將 refer 去掉，或者偽裝，這個辦法就無能為力了。但是貌似還有更高階的方法，還是可以實現這個功能。
        安裝apache的 mod_rewrite 模組後，在apache配置檔案中新增
        RewriteEngine On
        RewriteCond %{HTTP_REFERER} !^http://linuxidc.com/.*$ [NC]
        RewriteCond %{HTTP_REFERER} !^http://linuxidc.com$ [NC]
        RewriteCond %{HTTP_REFERER} !^http://www.linuxidc.com/.*$ [NC]
        RewriteCond %{HTTP_REFERER} !^http://www.linuxidc.com$ [NC]
        RewriteRule .*\.(gif|jpg|swf)$ http://www.linuxidc.com/about/nolink.png [R,NC]

        這樣盜鏈的請求會被重定向到一個錯誤頁面，從而減少下載帶給伺服器的壓力

另外一篇文章：再談Apache優化

週六公司的一臺伺服器負載過大，重啟
之後登陸上去查看了下httpd.conf和伺服器狀態
net -nap | grep :80 | wc -l 發現大量的連線數差不多有1萬多
net -nap | grep :80 | grep TIME_WAIT | wc -l 發現和總連線數非常接近大概9000多
net -nap | grep :80 | grep TIME_WAIT | grep 某ip | wc -l 發現有些ip time_wait個數居然有600多

檢查了httpd.conf
發現TIMEOUT 300 KeepAlive off
推斷 大量TIME_WAIT 是因為 TIMEOUT 時間過長， 單IP time_wait數過多是因為 KeepAlive off

修改配置
TIMEOUT 10
KeepAlive On
MaxKeepAliveRequests 400 #注這裡數字要大一些，但和apache允許客戶端總數相比要小很多
KeepAliveTimeout 10

重啟apache以後 net -nap | grep :80 | wc -l 降低到200多

第二天晚上高峰時觀察伺服器，除了偶爾負載高一些意外，一切正常

今天早上又給伺服器增加了頁面輸出壓縮模組，以加快資料傳輸速度，提高web伺服器的吞吐量
apache 版本 httpd-2.0.54
cd modules
cd filters
$APACHE_HOME/bin/apxs -I . -i -a -c -o mod_deflate.so mod_deflate.c
cd ../metadata/
$APACHE_HOME/bin/apxs -I . -i -a -c -o mod_headers.so mod_headers.c

vi $APACHE_HOME/conf/httpd.conf
增加

# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \ \.(?:gif|jpg|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary


這樣頁面輸出壓縮模組就安裝好了，晚上負載高的時候看執行效果
mod_deflate 模組可以細化到設定輸出 多大到多大範圍內的檔案才進行壓縮輸出，我這個只是簡單配置，具體其他配置看apache的文件了