本文主要闡述軟體性能測試中的一些調優思想和技術，節選自作者新書《軟體性能測試分析與調優實踐之路》部分章節歸納。
在國内網際網路公司中，Web中間件用的最多的就是Apache和Nginx這兩款了，包括很多大型電商網站淘寶、京東、蘇甯易購等，都在使用Nginx或者Apache作為Web中間件。而且很多程式設計語言在做Web開發時，會将Apache或者Nginx作為其綁定的固定元件，比如php語言做Web開發時，就經常和Apache聯系在一起，使得apche成為了php在Web開發時的一個标配。而Nginx不管是在作為Web靜态資源通路管理或者作為動态的請求代理性能都是非常的高效，當然Nginx或者Apache在性能分析時，有時候也會存在性能瓶頸或者需要進行調優以支援更高的并發處理能力。
1. Nginx的性能分析和調優
1.1 Nginx的負載均衡政策的選擇
在一般的時候，Web中間件最大的作用就是負責對請求進行分發，也就是我們常說的起到負載均衡的作用，當然負載均衡隻是Nginx的作用之一，Nginx常見的負載均衡政策一般包括輪詢、指定權重（weight）、ip_hash、least_conn、fair、url_hash等六種，其中預設執行的政策為輪詢，fair、url_hash屬于第三方政策，這兩種政策不是Nginx自帶支援的政策，需要安裝第三方的插件來輔助支援。在不同的場景下，每一種政策的選擇對系統的整體性能影響都非常大，一般建議根據實際場景和伺服器配置來選擇對應的負載均衡政策。
輪詢政策：Nginx的負載均衡是通過配置upstream來實作請求轉發的，在upstream如果沒有指定其他任何的政策時，Nginx會自動執行輪詢轉發政策，upstream中配置每台伺服器的權重都一樣，會按照順序依次轉發。如下所示就是一個簡單的upstream配置，由于配置了192.168.1.14和192.168.1.15兩台伺服器，是以請求會按照接收到的順序依次輪詢的轉發給192.168.1.14和192.168.1.15兩台伺服器進行執行。Nginx能自動感覺轉發到的後端伺服器是否挂掉，如果挂掉後Nginx會自動将那台挂掉的伺服器從upstream中剔除。
使用輪詢政策時，其他非必填的輔助參數如下：（轉載請注明出處:來源于部落格園，作者：張永清 https://www.cnblogs.com/laoqing/p/14259788.html）
使用輪詢政策的輔助參數
參數
含義
fail_timeout
該參數需要和max_fails參數結合一起來使用，用于表示在fail_timeout指定的時間内某個server允許重試連接配接失敗的最大次數
max_fails
在fail_timeout參數設定的時間内最大失敗次數，如果在這個時間内，所有針對該伺服器的請求都失敗了，Nginx就判定該伺服器挂掉了
down
标記指定的伺服器已經挂掉了，Nginx将不會再向标記為down的伺服器轉發任何的請求
指定權重（weight）：通過在upstream配置中給相應的伺服器指定weight權重參數來實作按照權重分發請求，weight參數值的大小和請求轉發比率成正比，一般用于後端應用程式伺服器硬體配置差異大而導緻承受的通路壓力不一樣的情況可以使用該配置，配置示例如下：
ip_hash：每個請求按原始通路ip的hash結果來進行請求轉發，由于同一個ip的hash值肯定是不變的，這樣每個固定用戶端就會隻通路一個後端應用程式伺服器，此種配置一般可以用來解決多個應用程式伺服器的session複制和同步的問題，因為同一個ip的請求都轉發到了同一台伺服器的應用程式上了，是以也就不會有session不同步的問題了，但是可能會導緻後端應用伺服器的負載不均的情況，因為這種政策下後端應用伺服器收到的請求數肯定是很難一樣多。配置示例如下：
least_conn：通過在upstream配置中增加least_conn配置後，Nginx在接收到請求後會把請求轉發給連接配接數較少的後端應用程式伺服器，前面講到的輪詢算法是把請求平均的轉發給各個後端使它們的負載大緻相同，但是有些請求占用的時間很長會導緻其所在的後端負載較高。這種情況下，least_conn這種方式就可以達到更好的負載均衡效果。示例配置如下：
fair：fair屬于第三方政策，即不是Nginx本身自帶的政策，需要安裝對應的第三方插件。fair是按照伺服器端的響應時間來配置設定請求給後端應用程式伺服器，響應時間短的優先配置設定。示例配置如下：
url_hash：url_hash同樣屬于第三方政策，也是需要安裝對應的第三方插件。url_hash是按照通路的目标url的hash值來配置設定請求使同一個url的請求轉發到同一個後端應用程式伺服器，請求的分發政策和ip_hash有點類似。在做性能調優時主要是适用對緩存命中進行調優，同一個資源（也就是同一個目标url位址）多次請求，可能會到達不同的後端應用程式伺服器上會導緻不必要的多次下載下傳，使用url_hash後可以使得同一個目标url（也就是同一個資源請求）會到達同一台後端應用程式伺服器，這樣可以在服務端進行資源緩存再次收到請求後，就可以直接從緩存中讀取了。示例配置如下：
1.2 Nginx程序數的配置優化
nginx服務啟動後會包括兩個重要的程序：
master程序：可以控制Nginx服務的啟動、停止 、重新開機、配置檔案的重新加載。
worker程序：處理使用者請求資訊，将收到的使用者請求轉發到後端應用伺服器上。
worker程序的個數可以在配置檔案nginx.conf中進行配置，如下所示。
worker程序的數量一般建議等于CPU的核數或者CPU核數的兩倍。通過執行lscpu指令可以擷取到CPU的核數，如圖所示。
或者通過執行grep processor /proc/cpuinfo|wc –l 指令也可以直接擷取到CPU的核數。
[root@localhost conf]#grep processor /proc/cpuinfo|wc -l
在配置完worker程序的數量後，還建議将每一個worker程序綁定到不同的CPU核上，這樣可以避免出現CPU的争搶。将worker程序綁定到不同的CPU核時可以通過在nginx.conf中增加worker_cpu_affinity 配置，例如将worker程序配置設定到4核的CPU上，可以按照如下配置進行配置。
1.3 Nginx事件處理模型的優化
為了性能得到最優處理，Nginx的連接配接處理機制在不同的作業系統中一般會采用不同的I/O事件模型，在Linux作業系統中一般使用epoll的I/O多路複用模型，在freebsd作業系統中使用kqueue的I/O多路複用模型，在solaris作業系統中使用/dev/pool方式的I/O多路複用模型，在windows作業系統中使用的icop模型。在實際使用Nginx時，我們也是需要根據不同的作業系統來選擇事件處理模型，很多事件模型都隻能在對應的作業系統上得到支援。比如我們在Linux作業系統中，可以使用如下配置來使用epoll事件處理模型。
關于I/O多路複用做個說明：在Nginx中可以配置讓一個程序處理多個I/O事件和多個調用請求，這種處理方式就類似Redis中的單線程處理模式一樣，Redis緩存讀寫處理時采用的雖然是單線程，但是性能和效率卻是非常的高，這就是因為Redis采用了異步非阻塞I/O多路複用的政策導緻資源的開銷很小，不需要重複的去建立和釋放資源，而是共用一個處理線程。Nginx中也同樣采用異步非阻塞I/O政策，每個worker程序會同時啟動一個固定的線程來利用epoll監聽各種需要處理的事件，當有事件需要處理時會将事件注冊到epoll模型中去進行處理，異步非阻塞I/O政策在處理時線程可以不用因為某個I/O的處理耗時很長而一直導緻線程阻塞等待，線程可以不用等待響應，也不必等待響應，而是可以繼續去處理其他的I/O事件。當I/O事件處理完成後，作業系統核心會通知I/O事件已經處理完成，這時線程才會去擷取處理好的結果。
下面表列出了Nginx常用事件處理模型的詳細介紹。
Nginx常用事件處理模型
處理模型
說明
select
各個版本的Linux和Windows作業系統都支援的基本事件驅動模型。select模型處理事件的步驟：
（1）、建立事件的描述符集合，包括讀、寫、異常發送三類事件描述符分别用來收集讀事件的描述符、寫事件的描述符和異常事件的描述符。
（2）、調用select模型底層提供的select函數等待事件發生。
（3）、輪詢所有事件描述符集合中的每一個事件描述符，檢查是否有相應的事件發生，如果有，select模型就進行相關的處理。
poll
Linux作業系統上的基本事件驅動模型，此模型無法在windows作業系統上使用。poll與select的共同點是都是先建立一個關注事件的描述符集合，再去等待這些事件發生，然後再輪詢描述符集合檢查有沒有事件發生，如果有就進行處理。不同點是select庫需要為讀事件、寫事件、異常事件分别建立一個描述符集合，是以在最後輪詢的時候，需要分别輪詢這三個集合。而poll庫隻需要建立一個集合，在每個描述符對應的結構上分别設定讀事件、寫事件、異常事件，最後輪詢的時候，可以同時檢查這三種事件是否發生
epoll
epoll庫是Nginx伺服器支援的高性能事件驅動模型之一，epoll屬于poll模型的一個變種，和poll主要差別在于epoll不需要使用輪詢的模式去檢查有沒有對應的事件發生，而是交給作業系統核心去負責處理，一旦有某種對應的事件發生時核心會把發生事件的描述符清單通知給程序，這樣就避免了輪詢整個描述符清單。epoll庫在Linux作業系統上是非常高效的，epoll可以同時處理的I/O事件數是作業系統可以打開檔案的最大數目，而且epoll庫的I/O效率不随描述符數目增加而線性下降，因為它隻會對作業系統核心回報的待處理的事件描述符進行操作
rtsig
rtsig模型不是一種經常用到的事件處理模型，rtsig模型在工作時會通過系統核心建立一個rtsig隊列用于存放标記事件發生的信号，每個事件發生時，系統核心就會産生一個信号存放到rtsig隊列中等待Nginx工作程序的處理
kqueue
Kqueue模型也是poll模型的一個變種，和上面介紹的epoll模型的處理方式幾乎一樣，都是通過避免輪詢操作提供效率。該模型支援在BSD系列作業系統（例如FreeBSD 、OpenBSD 、NetBSD 等）上使用
/dev/poll
/dev/poll模型一般用于solaris作業系統或者其他的unix衍生作業系統上，該模型最早是Sun公司在開發Solaris系列平台時提出的用于完成事件驅動機制的方案，它使用了虛拟的/dev/poll裝置，開發人員可以将要監視的檔案描述符加入這個裝置，然後通過調用ioctl()函數來擷取事件通知
eventport
該模型也是Sun公司在開發Solaris系列平台時提出的、用于完成事件驅動機制的方案，它可以有效防止核心崩潰情況的發生，Nginx在此基礎上提供了事件處理支援，但是由于Solaris自身後來的沒落，是以該模型現在也很少使用。
1.4 Nginx用戶端連接配接數的優化
在高并發的請求調用中，連接配接數有時候很容易成為性能的一個瓶頸，Nginx中可以通過如下方式來調整Nginx的連接配接數。
配置Nginx單個程序允許的用戶端最大連接配接數：可以通過修改Nginx的nginx.conf配置檔案中的如下配置：
配置Nginx worker程序可以打開的最大檔案數：可以通過修改Nginx的nginx.conf配置檔案中的如下配置：
Linux核心的優化：Linux作業系統的/etc/sysctl.conf配置檔案中可以重新配置很多Linux系統的核心參數
1.5 Nginx中檔案傳輸的優化
Nginx中檔案傳輸一般需要優化的是如表中所示的幾個參數。
Nginx檔案傳輸需要優化的參數
Nginx參數
tcp_nopush
tcp_nopush和tcp_nodelay是互斥的，開啟tcp_nopush後會設定調用tcp_cork方法，讓資料包不會馬上傳送出去，等到資料包累積到最大時，一次性的傳輸出去，這樣有助于解決網絡堵塞，進而提供網絡傳輸的性能，預設為off。設定為on時的配置如下：
tcp_nopush on;
tcp_nodelay
和tcp_nopush的處理方式剛好相反，在開啟了tcp_nodelay後意味着無論資料包是多麼的小，都立即發送出去，預設值為on，設定為off時為關閉，配置的方式如下：
tcp_nodelay off;
sendfile
sendfile 一般和tcp_nopush選項搭配在一起使用。Nginx中提供 sendfile 選項用來提高伺服器性能，sendfile實際上是 Linux2.0版本以後推出的一個系統調用。在網絡檔案傳輸過程中一般是：從硬碟讀寫 → 寫入作業系統核心 buffer → 讀入使用者模式 buffer-> 寫入核心socket buffer →協定棧開始傳輸，在開啟了sendfile後，之前的傳輸步驟就簡化成了：從硬碟讀寫 → 寫入核心 buffer (資料可以快速拷貝到核心 socket buffer) →協定棧開始傳輸，這就是常說的零拷貝方式。開啟sendfile的配置如下：
sendfile on;
nginx gzip壓縮相關參數：
gzip on
gzip_min_length
gzip_buffers
gzip_http_version
gzip_comp_level
gzip_types
gzip_vary
gzip_proxied off
gzip on：開啟gzip 壓縮模式
gzip_min_length ：設定允許壓縮的頁面最小宇節數，位元組數大小 從HTTP請求的header頭部的Content-Length中擷取。預設值是0，表示不管頁面多大都進行壓縮。一般建議設定成gzip_min_length 1K,因為如果小于1K可能會越壓越大。
gzip_buffers：表示壓縮緩沖區大小，例如設定gzip_buffers 4 16k; 表示申請4個機關為16K的記憶體作為壓縮結果資料流的緩存，預設值是申請與原始資料大小相同的記憶體空間來存儲gzip壓縮結果。
gzip_http_version：表示壓縮的HTTP協定版本，預設為1.1，常用的浏覽器幾乎都支援gzip解壓，一般使用預設設定即可。
gzip_comp_level：表示gzip的壓縮比率，該參數用來指定gzip壓縮比，可以設定為1-9之間的數字。1表示壓縮比最小但是壓縮處理速度最快，9表示壓縮比最大并且傳輸速度快，但處理時耗時最長也比較消耗CPU資源。該參數一般建議根據實際場景中傳輸的大部分檔案大小來設定，在壓縮處理速度和壓縮比率大小之間做到均衡。
gzip_types：用來設定指定壓縮的類型（就是HTTP協定中的Content-Type屬性中的媒體類型）， 支援的常見類型包括 text/plain、application/x-javascript 、text/css、 application/xml、application/json等。
gzip_vary：表示啟用response header頭部屬性“Vary:Accept-Encoding”的壓縮模式。[z1]
zip_proxied off：預設為off，一般在Nginx作為反向代理的時候啟用，表示對代理的結果資料進行壓縮，zip_proxied可以在後面增加參數來判斷HTTP的header頭部中符合指定條件後才進行資料壓縮。
loff ：關閉所有的代理結果資料的壓縮。
lexpired ：啟用壓縮，如果header頭部中包含 "Expires" 頭資訊。
lno-cache：啟用壓縮，如果header頭部中包含 "Cache-Control:no-cache" 頭資訊。
lno-store：啟用壓縮，如果header頭部中包含 "Cache-Control:no-store" 頭資訊。
lprivate：啟用壓縮，如果header頭部中包含"Cache-Control:private" 頭資訊。
lno_last_modified：啟用壓縮，如果header頭部中不包含 "Last-Modified" 頭資訊。
lno_etag：啟用壓縮，如果header頭部中不包含 "ETag" 頭資訊。
lauth：啟用壓縮，如果header頭部中包含 "Authorization" 頭資訊。
lany：表示總是啟用壓縮，表示會對傳回的代理資料都進行壓縮。
[z1]
在nginx.conf配置檔案中開啟sendfile參數的方式配置示例如下：
在nginx.conf配置檔案中開啟tcp_nopush參數的方式配置示例如下：
在nginx.conf配置檔案中開啟tcp_nodelay參數的方式配置示例如下：
1.6 Nginx中FastCGI配置的優化
FastCGI是在CGI基礎上的優化更新，CGI是Web伺服器與CGI程式間傳輸資料的一種标準，運作在伺服器上的CGI程式按照這個協定标準提供了傳輸接口，具體介紹如下。
CGI：CGI是英文common gateway interface的簡寫，翻譯過來就是通用網關接口，這套接口描述了Web伺服器與同一計算機上的軟體的通信方式，有了CGI标準後內建了CGI的Web伺服器就可以通過CGI接口調用伺服器上各種動态語言實作的程式了，這些程式隻要通過CGI标準提供對應的調用接口即可。CGI的處理的一般流程如圖所示。
l FastCGI：FastCGI是一個傳輸快速可伸縮的用于HTTP伺服器和動态腳本語言間通信的接口，它為所有Internet應用程式提供了高性能，而不受Web伺服器API的限制。包括Apache、Nginx在内的大多數Web服務都支援FastCGI，同時FastCGI也被許多腳本語言（例如Python、PHP等）所支援。
Nginx本身并不支援對外部動态程式的直接調用或者解析，所有的外部程式設計語言編寫的程式（比如Python、PHP）必須通過FastCGI接口才能調用。FastCGI相關參數說明如表所示。
FastCGI相關參數說明
Nginx FastCGI相關參數
fastcgi_connect_timeout
用于設定Nginx伺服器和後端FastCGI程式連接配接的逾時時間，預設值值為60秒，一般建議不要超過75秒，時間太長會導緻高并發調用下建立連接配接過多而不能及時釋放，建立的連接配接越多消耗的資源就會越多
fastcgi_send_timeout
用于設定Nginx發送CGI請求到FastCGI程式的逾時時間，這個逾時時間不是整個請求的逾時時間，而是兩個成功請求的之間間隔時間為逾時時間，如果這個時間内FastCGI服務沒有收到任何資訊連接配接将被關閉
fastcgi_read_timeout
用于設定Nginx從FastCGI伺服器讀取響應資訊的逾時時間，連接配接建立成功後 Nginx等待後端FastCGI程式的響應時間，實際上是讀取FastCGI響應成功消息的間隔時間，如果這個時間内Nginx沒有再次從FastCGI讀取到響應消息連接配接就會被關閉
fastcgi_buffer_size
用于設定Nginx FastCGI的緩沖區的大小，緩沖區大小表示的是讀取從FastCGI程式端收到的第一部分響應資訊的緩沖區大小，這裡的第一部分通常會包含一個小的響應頭部消息，預設情況下這個參數的大小等價于作業系統的1個記憶體頁機關的大小，一般是4k或者8k， 在不同的作業系統上預設大小可能不同
fastcgi_buffers
用于設定Nginx用多少和多大的緩沖區讀取從FastCGI程式收到的響應資訊，預設值為fastcgi_buffer 8 4k|8k;可以在nginx.conf配置檔案的的http、server、location這三個字段中使用。
一般用于指定Web伺服器本地需要用多少和多大的緩沖區來緩沖FastCGI的應答請求，比如如果一個fastcgi程式的響應消息大小為12k，那麼配置為fastcgi_buffers 6 4k時将配置設定3個4k的buffer
fastcgi_busy_buffers_size
用于設定伺服器很忙時可以使用的fastcgi_buffers大小，一般推薦的大小為fastcgi_buffers*2；預設值為 fastcgi_busy_buffers_size 8k|16k
fastcgi_temp_file_write_size
用于設定FastCGI臨時檔案的大小，一般建議可以設定為128~256KB ，預設大小為fastcgi_temp_file_write_size 8k|16k;
fastcgi_cache myboy_nginx
用于設定開啟FastCGI緩存功能并為其指定一個名稱（比如指定為myboy_nginx）。開啟緩存可以有效降低CPU的負載并且可以防止HTTP請求的502錯誤（HTTP伺服器端的一個錯誤碼，一般是指上遊伺服器接收到無效的響應）的發生，而且合理設定該參數可以有效的提高請求的并發數和tps
fastcgi_cache_path
用于設定fastcgi_cache的緩存路徑。
例如可以設定為：fastcgi_cache_path /opt/data/nginx/cache levels = 2:2 keys_zone = nginx_ fastcgi_cache:256m inactive = 2d max_size=80g use_temp_path=on；fastcgi_cache的緩存路徑可以設定目錄前列層級，比如2:2會生成256*256 個子目錄，keys_zone是設定這個緩存空間的名字以及使用多少實體記憶體（一般經常被通路的熱點資料Nginx會直接放入記憶體以提高通路速度），nginx_ fastcgi _cache:256m表示緩存空間的名字為nginx_ fastcgi_cache，大小為256m。inactive表示預設失效時間，max_size表示最多用多少硬碟空間來存儲緩存，特别要注意的是fastcgi_cache緩存是先寫在fastcgi_temp_path，等到達一定大小後再移到fastcgi_cache_path下去的，是以這個兩個目錄最好在同一個磁盤分區下以提高I/O讀寫速度, 如果設定use_temp_path=off則 nginx 會将緩存檔案直接寫入指定的 cache 檔案中
fastcgi_temp_path
用于設定fastcgi_cache的臨時目錄路徑，例如可以設定為fastcgi_temp_path /usr/local/nginx/fastcgi_temp
fastcgi_cache_valid
用于對不同的HTTP 請求響應狀态碼設定緩存的時長。
例如：fastcgi_cache_valid 200 302 lh;
表示将HTTP 請求響應狀态碼為200和302的應答緩存1個小時。
再例如：fastcgi_cache_valid 301 2d;
表示将HTTP 請求響應狀态碼為301的應答緩存2天
fastcgi_cache_min_uses
用于設定同一請求達到幾次之後晌應消息将被緩存。
例如：fastcgi_cache_min_uses 1;1表示一次即被緩存
fastcgi_cache_use_stale
用于設定哪些狀态下使用過期緩存。
例如：fastcgi_cache_use_stale error timeout invalid_header http_500 表示在發生error錯誤、響應逾時、HTTP的請求頭無效和HTTP請求傳回狀态碼為500時使用過期緩存
fastcgi_cache_key
用于設定fastcgi_cache中的key值。
例如：fastcgi_cache_key scheme$request_method$host$request_uri
表示以請求的URI作為緩存的key，Nginx會取這個key的md5作為緩存檔案，如果設定了緩存的目錄，Nginx會從後往前取對應的位數作為目錄。建議一定要加上$request_method變量一起作為cache key，防止如果先請求的為head 類型（HTTP請求的一種類型，類似于get請求，隻不過傳回的響應中沒有具體的響應内容，僅用于擷取響應封包的頭部資訊），後面的GET請求将傳回為空
1.7 Nginx的監控
Nginx自帶了監控子產品，但是需要在Nginx編譯安裝時指定安裝監控子產品，預設情況下是不會安裝該監控子產品的，需要指定的編譯參數為--with-http_stub_status_module。
編譯安裝完成後，Nginx的配置檔案nginx.conf中還是不會開啟監控，需要在配置檔案中增加如下配置，其中allow 192.168.1.102代表允許通路監控頁面的ip位址，如圖所示。
修改完配置檔案後，通過執行nginx –s reload來重新加載配置資訊，然後通過通路http://nginx伺服器ip位址:端口号/nginx_status 就可以進入監控頁面了，如圖所示。
從圖中可以看到目前已經建立的連接配接數、伺服器已經接收的請求數、請求的處理情況等監控資訊。
2、Apache的性能分析和調優
在Web中間件中除了Nginx外另一個用的最多的中間件就是Apache了，Apache幾乎可以運作在所有的作業系統中，支援HTTP、SSL、Socket、FastCGI、SSO、負載均衡、伺服器代理等很多功能子產品，在性能測試分析中如果對Apache使用不當，那麼Apache有時候也可能會成為高并發通路的瓶頸。
2.1 Apache的工作模式選擇和程序數調優
Apache的工作模式主要是指Apache在運作時記憶體配置設定、CPU、程序以及線程的使用管理和請求任務的排程等。Apache比較穩定的工作模式有prefork模式、worker模式、event模式，這三種模式也是Apache經常使用的模式。Apache預設使用的是prefork模式，一般可以在編譯安裝Apache時通過參數--with-mpm來指定安裝後使用的工作模式。
可以通過執行httpd –V指令來檢視Apache目前使用的工作模式，如圖所示可以看到目前的工作模式為預設的prefork模式。
1. prefork模式
prefork是Apache的預設工作模式，采用非線程型的預派生方式來處理請求，在工作時使用多程序，每個程序在同一個固定的時間隻單獨處理一個連接配接，這種方式效率高但由于是多程序的方式是以記憶體使用比較大。如圖所示，可以看到prefork模式下啟動了多個程序。
prefork工作模式在收到請求後的處理過程如圖所示，從圖中可以看到處理過程是單程序和單線程的方式，由于不存線上程安全問題是以這種模式非常适合于沒有線程安全庫，需要避免線程安全性問題的系統。雖然解決了線程安全問題，但是也必然會導緻無法處理高并發請求的場景，prefork模式會将請求放進隊列中，一直等到有可用子程序請求才會被處理，也很容易導緻請求隊列積壓。
prefork工作模式主要的配置參數如表所示。
表 prefork工作模式主要的配置參數說明
StartServers
啟動的server程序個數，也就是啟動多少個子程序來處理請求，預設值為5
MinSpareServers
空閑子程序的最小數量，預設值為5，如果目前空閑子程序數少于MinSpareServers ，那麼Apache會以最大每秒一個的速度産生新的子程序。一般不建議參數設定的過大，可以根據實際的并發請求量來進行設定
MaxSpareServers
空閑子程序的最大數量，預設值為10。如果目前有超過MaxSpareServers數量的空閑子程序，那麼主程序會殺死多餘的子程序
MaxRequestWorkers
代表伺服器在同一時間内可以處理用戶端發送的最大請求數量，預設是256。當超過了MaxRequestWorkers大小限制的請求就會進入等待隊列進行排隊
MaxConnectionsPerChild
每個子程序在其生命周期内允許接收處理的最大請求數量。如果請求總數已經達到這個數值，子程序将會結束，在有新的請求時就會重新開啟新的子程序。如果設定為0，子程序将永遠不會結束。該值不宜設定的過小，過小的話會容易導緻程序頻繁的開啟和關閉，引起CPU的上下文切換過多。當然也建議不要設定為0，非0的情況下由于子程序肯定都存在生命周期，這樣可以防止記憶體洩漏以及有效的快速釋放不能釋放的資源
2. worker模式
worker模式使用了多程序和多線程相結合的混合模式來處理請求，如圖所示work模式下也是主程序會首先派生出一批子程序，但和prefork模式不同的是work模式下每個子程序會建立多個線程，每個請求會配置設定給一個不同的線程處理。work模式中處理請求時由于采用了多線程的處理方式，是以高并發下處理能力會更強，但是由于是多線程處理方式，是以這種模式下需要考慮線程安全問題。
轉載請注明出處:來源于部落格園，作者：張永清 https://www.cnblogs.com/laoqing/p/14259788.html
worker工作模式主要的配置參數如表所示。
表 worker工作模式主要的配置參數說明
Apache服務啟動時初始啟動的子程序數量，在workers模式下預設是3
ServerLimit
系統允許啟動的最大程序數量
MinSpareThreads
伺服器保持啟動的最小線程數
MaxSpareThreads
伺服器保持啟動的最大線程數
ThreadsPerChild
每個子程序允許啟動的線程數
MaxRequestWorkers /MaxClients
代表伺服器在同一時間内可以處理用戶端發送的最大請求數量
和prefork工作模式一樣，代表每個子程序在其生命周期内允許接收處理的最大請求數量。如果請求總數已經達到這個數值，子程序将會結束，在有新的請求時就會重新開啟新的子程序。如果設定為0，子程序将永遠不會結束
轉載請注明出處:來源于部落格園，作者：張永清 https://www.cnblogs.com/laoqing/p/14259788.html
3. event模式
event模式和worker工作模式有點類似，在event工作模式中會有一些專門的線程來承擔管理和配置設定線程的工作，通過這種方式使event工作模式解決了HTTP請求 keep-alive長連接配接的時候占用線程資源被浪費的問題，因為會有一些專門的線程用來管理這些keep-alive類型的工作線程，當有真實請求過來的時候，将請求傳遞給伺服器端可用的工作線程進行處理，處理完畢後又允許其釋放資源。如圖所示。
event工作模式主要的配置參數如下：
event工作模式的配置參數幾乎與worker模式是一樣的，因為event模式本身就是對worker模式的一種更新改進。
2.2 Apache的mod選擇和優化
未完待續，更多内容
備注：作者的原創文章，轉載須注明出處。原創文章歸作者所有，歡迎轉載，但是保留版權。對于轉載了部落客的原創文章，不标注出處的，作者将依法追究版權，請尊重作者的成果。
關于軟體性能分析調優，可以加微信号yq597365581或者微信号hqh345932，進入專業的性能分析調優群進行交流溝通。
作者的原創文章，轉載須注明出處。原創文章歸作者所有，歡迎轉載，但是保留版權。對于轉載了部落客的原創文章，不标注出處的，作者将依法追究版權，請尊重作者的成果。