freebsdnginxphp

1. 面試官：請問Nginx為什麼比Apache性能好

Nginx才短短幾年，就拿下了web伺服器大筆江山，眾所周知，Nginx在處理大並發靜態請求方面，效率明顯高於httpd，甚至能輕松解決C10K問題。下面我們就來聊聊Web伺服器背後的一些原理。

進程是具有一定獨立功能的，在計算機中已經運行的程序的實體。在早期系統中（如linux 2.4以前），進程是基本運作單位，在支持線程的系統中（如windows，linux2.6）中，線程才是基本的運作單位，而進程只是線程的容器。程序本身只是指令、數據及其組織形式的描述，進程才是程序（那些指令和數據）的真正運行實例。若干進程有可能與同一個程序相關系，且每個進程皆可以同步（循序）或非同步（平行）的方式獨立運行。現代計算機系統可在同一段時間內以進程的形式將多個程序載入到存儲器中，並藉由時間共享（或稱時分復用），以在一個處理器上表現出同時（平行性）運行的感覺。同樣的，使用多線程技術（多線程即每一個線程都代表一個進程內的一個獨立執行上下文）的操作系統或計算機架構，同樣程序的平行線程，可在多 CPU 主機或網路上真正同時運行（在不同的CPU上）。

Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理檔讓用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。多進程方式：為每個請求啟動一個進程來處理。由於在操作系統中，生成進程、銷毀進程、進程間切換都很消耗CPU和內存，當負載高是，性能會明顯降低。優點： 穩定性！由於採用獨立進程處理獨立請求，而進程之間是獨立的，單個進程問題不會影響其他進程，因此穩定性最好。缺點： 資源佔用！當請求過大時，需要大量的進程處理請求，進程生成、切換開銷很大，而且進程間資源是獨立的，造成內存重復利用。多線程方式：一個進程中用多個線程處理用戶請求。由於線程開銷明顯小於進程，而且部分資源還可以共享，因此效率較高。優點：開銷較小！線程間部分數據是共享的，且線程生成與線程間的切換所需資源開銷比進程間切換小得多。缺點：穩定性！線程切換過快可能造成線程抖動，且線凳蠢廳程過多會造成伺服器不穩定。非同步方式：使用非阻塞方式處理請求，是三種方式中開銷最小的。但非同步方式雖然效率高，但要求也高，因為多任務之間的調度如果出現問題，就可能出現整體故障，因此使用非同步工作的，一般是一些功能相對簡單，但卻符合伺服器任務調度、且代碼中沒有影響調度的錯誤代碼存在的程序。優點：性能最好！一個進程或線程處理多個請求，不需要額外開銷，性能最好，資源佔用最低。缺點：穩定性！某個進程或線程出錯，可能導致大量請求無法處理，甚至導致整個服務宕機。

從上圖中我們可以看出，可以看出，越往後，阻塞越少，理論上效率也是最優。其五種I/O模型中，前三種屬於同步I/O，後兩者屬於非同步I/O。

同步I/O:

非同步I/O:

非同步 I/O 和 信號驅動I/O的區別:

注，其中iocp是Windows實現的，select、poll、epoll是Linux實現的，kqueue是FreeBSD實現的，/dev/poll是SUN的Solaris實現的。select、poll對應第3種（I/O復用）模型，iocp對應第5種（非同步I/O）模型，那麼epoll、kqueue、/dev/poll呢？其實也同select屬於同一種模型，只是更高級一些，可以看作有了第4種（信號驅動I/O）模型的某些特性，如callback機制。

答案是，他們無輪詢。因為他們用callback取代了。想想看，當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度，不管哪個Socket是活躍的，都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll、kqueue、/dev/poll做的。這樣子說可能不好理解，那麼我說一個現實中的例子，假設你在大學讀書，住的宿舍樓有很多間房間，你的朋友要來找你。select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。而epoll版宿管大媽會先記下每位同學的房間號，你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。如果來了10000個人，都要找自己住這棟樓的同學時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高並發伺服器中，輪詢I/O是最耗時間的操作之一，select、epoll、/dev/poll的性能誰的性能更高，同樣十分明了。

誠然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系統，但是由於其系統本身的局限性，大型伺服器還是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 與 IOCP相比，就是多了一層從內核數據到應用層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue、epoll、/dev/poll 已經做得很優秀了。

只有IOCP(windows實現)是asynchronous I/O，其他機制或多或少都會有一點阻塞。select（Linux實現）低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善epoll(Linux實現)、kqueue（FreeBSD實現）、/dev/poll（Solaris實現）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9之前只支持select模型，2.2.9之後支持epoll模型Nginx 支持epoll模型Java nio包是select模型

我們都知道Apache有三種工作模塊，分別為prefork、worker、event。prefork：多進程，每個請求用一個進程響應，這個過程會用到select機制來通知。worker：多線程，一個進程可以生成多個線程，每個線程響應一個請求，但通知機制還是select不過可以接受更多的請求。event：基於非同步I/O模型，一個進程或線程，每個進程或線程響應多個用戶請求，它是基於事件驅動（也就是epoll機制）實現的。

如果不用「--with-mpm」顯式指定某種MPM,prefork就是Unix平台上預設的MPM.它所採用的預派生子進程方式也是 Apache1.3中採用的模式。prefork本身並沒有使用到線程，2.0版使用它是為了與1.3版保持兼容性；另一方面，prefork用單獨的子進程來處理不同的請求，進程之間是彼此獨立的,這也使其成為最穩定的MPM之一。

相對於prefork，worker是2.0版中全新的支持多線程和多進程混合模型的MPM。由於使用線程來處理，所以可以處理相對海量的請求，而系統資源的開銷要小於基於進程的伺服器。但是，worker也使用了多進程,每個進程又生成多個線程，以獲得基於進程伺服器的穩定性，這種MPM的工作方 式將是Apache2.0的發展趨勢。

一個進程響應多個用戶請求，利用callback機制，讓套接字復用，請求過來後進程並不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，進程本身一直處於空閑狀態，可以一直接收用戶請求。可以實現一個進程程響應多個用戶請求。支持持海量並發連接數，消耗更少的資源。

有幾個基本條件：

剛好，Nginx 支持以上所有特性。所以Nginx官網上說，Nginx支持50000並發，是有依據的。

傳統上基於進程或線程模型架構的web服務通過每進程或每線程處理並發連接請求，這勢必會在網路和I/O操作時產生阻塞，其另一個必然結果則是對內存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境，這包括為其分配堆內存和棧內存，以及為其創建新的執行上下文等。這些操作都需要佔用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統性能也會由此進一步下降。另一種高性能web伺服器/web伺服器反向代理：Nginx（Engine X），nginx的主要著眼點就是其高性能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啟發於多種操作系統設計中基於「事件」的高級處理機制，nginx採用了模塊化、事件驅動、非同步、單線程及非阻塞的架構，並大量採用了多路復用及事件通知機制。在nginx中，連接請求由為數不多的幾個僅包含一個線程的進程worker以高效的回環(run-loop)機制進行處理，而每個worker可以並行處理數千個的並發連接及請求。

Nginx會按需同時運行多個進程：一個主進程(master)和幾個工作進程(worker)，配置了緩存時還會有緩存載入器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程，並主要通過「共享內存」的機制實現進程間通信。主進程以root用戶身份運行，而worker、cache loader和cache manager均應以非特權用戶身份運行。

主進程主要完成如下工作：

註：如果負載以CPU密集型應用為主，如SSL或壓縮應用，則worker數應與CPU數相同；如果負載以IO密集型為主，如響應大量內容給客戶端，則worker數應該為CPU個數的1.5或2倍。

Nginx的代碼是由一個核心和一系列的模塊組成, 核心主要用於提供Web Server的基本功能，以及Web和Mail反向代理的功能；還用於啟用網路協議，創建必要的運行時環境以及確保不同的模塊之間平滑地進行交互。不過，大多跟協議相關的功能和某應用特有的功能都是由nginx的模塊實現的。這些功能模塊大致可以分為事件模塊、階段性處理器、輸出過濾器、變數處理器、協議、upstream和負載均衡幾個類別，這些共同組成了nginx的http功能。事件模塊主要用於提供OS獨立的(不同操作系統的事件機制有所不同)事件通知機制如kqueue或epoll等。協議模塊則負責實現nginx通過http、tls/ssl、smtp、pop3以及imap與對應的客戶端建立會話。在Nginx內部，進程間的通信是通過模塊的pipeline或chain實現的；換句話說，每一個功能或操作都由一個模塊來實現。例如，壓縮、通過FastCGI或uwsgi協議與upstream伺服器通信，以及與memcached建立會話等。

處理靜態文件，索引文件以及自動索引；反向代理加速(無緩存)，簡單的負載均衡和容錯；FastCGI，簡單的負載均衡和容錯；模塊化的結構。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求並發處理；SSL 和 TLS SNI 支持；

使用外部 HTTP 認證伺服器重定向用戶到 IMAP/POP3 後端；使用外部 HTTP 認證伺服器認證用戶後連接重定向到內部的 SMTP 後端；認證方法：POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;IMAP: IMAP LOGIN;SMTP: AUTH LOGIN PLAIN CRAM-MD5;SSL 支持；在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;MacOS X (10.4) PPC;Windows 編譯版本支持 windows 系列操作系統

一個主進程和多個工作進程，工作進程運行於非特權用戶；kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （臨時禁止事件）， NOTE_LOWAT, EV_EOF, 有效數據的數目，錯誤代碼；sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；輸入過濾 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；10,000 非活動的 HTTP keep-alive 連接僅需要 2.5M 內存。最小化的數據拷貝操作；

基於IP 和名稱的虛擬主機服務；Memcached 的 GET 介面；支持 keep-alive 和管道連接；靈活簡單的配置；重新配置和在線升級而無須中斷客戶的工作進程；可定製的訪問日誌，日誌寫入緩存，以及快捷的日誌回卷；4xx-5xx 錯誤代碼重定向；基於 PCRE 的 rewrite 重寫模塊；基於客戶端 IP 地址和 HTTP 基本認證的訪問控制；PUT, DELETE, 和 MKCOL 方法；支持 FLV （Flash 視頻）；帶寬限制；

在高連接並發的情況下，Nginx是Apache伺服器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一. 能夠支持高達 50,000 個並發連接數的響應, 感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型。Nginx作為負載均衡伺服器: Nginx 既可以在內部直接支持 Rails 和 php 程序對外進行服務, 也可以支持作為 HTTP代理 伺服器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。作為郵件代理伺服器: Nginx 同時也是一個非常優秀的郵件代理伺服器（最早開發這個產品的目的之一也是作為郵件代理伺服器）, Last.fm 描述了成功並且美妙的使用經驗.Nginx 安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）,Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啟動. 你還能夠 不間斷服務的情況下進行軟體版本的升級 。Nginx 的誕生主要解決C10K問題

2. Nginx 和 Apache 各有什麼優缺點

1、nginx相對於apache的優點：
輕量級，同樣起web 服務，比apache佔用更少的內存及資源
抗並發，nginx 處理請求是非同步非阻塞的，而apache 則是阻塞型的，在高並發下nginx 能保持低資源低消耗高性能
高度模塊化的設計，編寫模塊相對簡單
社區活躍，各種高性能模塊出品迅速啊
apache 相對於nginx 的優點：

rewrite ，比nginx 的rewrite 強大
動態頁面
模塊超多，基本想到的都可以找到
少bug ，nginx 的bug 相對較多

超穩定

存在就是理由，一般來說，需要性能的web 服務，用nginx 。如果不需要性能只求穩定，那就apache 吧。
後者的各種功能模塊實現得比前者，例如ssl 的模塊就比前者好，可配置項多。這里要注意一點，epoll(freebsd 上是 kqueue )網路
IO 模型是nginx 處理性能高的根本理由，但並不是所有的情況下都是epoll 大獲全勝的，如果本身提供靜態服務的就只有寥寥幾個文
件，apache 的select 模型或許比epoll 更高性能。當然，這只是根據網路IO 模型的原理作的一個假設，真正的應用還是需要實測了再說
的。

2、作為 Web 伺服器：相比 Apache，Nginx 使用更少的資源，支持更多的並發連接，體現更高的效率，這點
使 Nginx 尤其受到虛擬主機提供商的歡迎。在高連接並發的情況下，Nginx是Apache伺服器不錯的替代品: Nginx在美國是做虛擬主機生
意的老闆們經常選擇的軟體平台之一. 能夠支持高達 50,000 個並發連接數的響應, 感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型.
Nginx
作為負載均衡伺服器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作為 HTTP代理 伺服器對外進行
服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多.
作為郵件代理伺服器: Nginx 同時也是一個非常優秀的郵件代理伺服器（最早開發這個產品的目的之一也是作為郵件代理伺服器）, Last.fm 描述了成功並且美妙的使用經驗.
Nginx 是
一個安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）, Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到
7*24不間斷運行，即使運行數個月也不需要重新啟動. 你還能夠不間斷服務的情況下進行軟體版本的升級 .

3、Nginx 配置簡潔, Apache 復雜
Nginx 靜態處理性能比 Apache 高 3倍以上
Apache 對 PHP 支持比較簡單，Nginx 需要配合其他後端用
Apache 的組件比 Nginx 多
現在 Nginx 才是 Web 伺服器的首選

4、最核心的區別在於apache是同步多進程模型，一個連接對應一個進程；nginx是非同步的，多個連接（萬級別）可以對應一個進程

5、nginx處理靜態文件好,耗費內存少.但無疑apache仍然是目前的主流,有很多豐富的特性.所以還需要搭配著來.當然如果能確定nginx就適合需求,那麼使用nginx會是更經濟的方式.
apache有先天不支持多核心處理負載雞肋的缺點，建議使用nginx做前端，後端用apache。大型網站建議用nginx自代的集群功能

6、
從個人過往的使用情況來看，nginx的負載能力比apache高很多。最新的伺服器也改用nginx了。而且nginx改完配置能-t測試一下配置有沒
有問題，apache重啟的時候發現配置出錯了，會很崩潰，改的時候都會非常小心翼翼現在看有好多集群站，前端nginx抗並發，後端apache集群，
配合的也不錯。

7、nginx處理動態請求是雞肋，一般動態請求要apache去做，nginx只適合靜態和反向。

8、從我個人的經驗來看，nginx是很不錯的前端伺服器，負載性能很好，在老奔上開nginx，用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好，此外apache有強大的支持網路，發展時間相對nginx更久，

9、
Nginx優於apache的主要兩點：1.Nginx本身就是一個反向代理伺服器 2.Nginx支持7層負載均衡；其他的當然，Nginx可能會比
apache支持更高的並發，但是根據NetCraft的統計，2011年4月的統計數據，Apache依然佔有62.71%，而Nginx是
7.35%，因此總得來說，Aapche依然是大部分公司的首先，因為其成熟的技術和開發社區已經也是非常不錯的性能。

10、你對web server的需求決定你的選擇。大
部分情況下nginx都優於APACHE，比如說靜態文件處理、PHP-CGI的支持、反向代理功能、前端Cache、維持連接等等。在
Apache+PHP（prefork）模式下，如果PHP處理慢或者前端壓力很大的情況下，很容易出現Apache進程數飆升，從而拒絕服務的現象。

11、可以看一下nginx lua模塊：apache比nginx多的模塊，可直接用lua實現apache是最流行的，why？大多數人懶得更新到nginx或者學新事物

12、對於nginx，我喜歡它配置文件寫的很簡潔，正則配置讓很多事情變得簡單運行效率高，佔用資源少，代理功能強大，很適合做前端響應伺服器

13、Apache在處理動態有優勢，Nginx並發性比較好，CPU內存佔用低，如果rewrite頻繁，那還是Apache吧

3. 我的freebsd系統下Nginx PHP提示出現The page you are looking for is temporarily unavailable錯誤

1.先檢查PHP FastCGI進程數是否夠用：
netstat -anpo|grep 「php-cgi」|wc -l
如果輸出為0的話，則表示FastCGI 進程數夠大，

2.此時則修改scgi_params文件，找到：

scgi_param SCGI 1;

把它改為：

scgi_param SCGI 5;

3.PHP程序如果的執行時間超過了Nginx的等待時間，就可適當地增加nginx.conf配置文件中FastCGI的timeout時間，例如：
http
{
……
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k
fastcgi_buffers 4 64k
……
}

4.重啟FastCGI

先殺掉進程：# pkill -9 php-cgi
然後重啟：# /usr/local/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/local/bin/php-cgi

5.重啟Nginx

先殺掉進程:# killall -9 nginx
然後重啟：# /usr/local/sbin/nginx

其它可能情況：

1)訪問任意PHP文件，出現

The page you are looking for is temporarily unavailable.
Please try again later.

2)訪問html頁面，正常

原因:
nginx不能正常通過FastCGI結果訪問PHP

1)如果是以tcp socket形式，可能是進程用戶許可權設置得不對

spawn-fcgi -a 127.0.0.1 -p 9000 -C 2 -u www-data -g www-data -f /usr/bin/php-cgi

可以改為 www-data 或者 nobody, 重啟php-cgi進程

2)如果是unix socket,可能 socket文件許可權沒有寫入能力

srwxrwxr-x 1 gavin gavin 0 11-12 10:18 php-fcgi.sock

為其他用戶添加寫入能力

chmod o+w php-fcgi.sock

4. 一名優秀的Linux運維人員該掌握哪些工具

運維人員必須熟悉的運維工具匯總
某日受邀請參加了一個BBS活動，於是有了下面的內容。
下面是在linux網站運維方向老男孩最近幾年常用的免費的開源軟體，臨時即興想起來的，在這里和大家分享，希望給初學者指引一點路。
linux的世界真的很精彩，還沒入門的朋友趕緊進來吧！
操作系統：Centos※,Ubuntu,Redhat※,suse，Freebsd
網站服務：nginx※,apache※,lighttpd,php※,tomcat※,resin※
數據 庫：MySQL※,Mysql-proxy,MariaDB，PostgreSQL
DB中間件：MyCat,amoeba,MySQL-proxy
代理相關：lvs,keepalived,haproxy,nginx,apache,heartbeat（此行都是※）
網站緩存：squid※,nginx※,varnish
NOSQL庫：memcached※,memcachedb,TokyoTyrant※,MongoDB※,Cassandra※,redis※,CouchDB
存儲相關：Nfs※,Moosefs(mfs)※,Hadoop※,glusterfs※,lustre,FastDFS
版本管理：svn※,git※
監控報警：nagios※,cacti※,zabbix※,munin,hyperic,mrtg,graphite
域名解析：bind※,powerdns,dnsmasq※
同步軟體：rsync※,inotify※,sersync※,drbd※,csync2,union,lsyncd,scp※
批量管理：ssh+rsync+sersync※,Saltstack※,expect※,puppet※,ansible,cfengine
虛擬 化：kvm※,xen※
雲計 算：openstack※,docker,cloudstack
內網軟體：iptables※,zebra※,iftraf,ntop※,tc※,iftop
郵件軟體：qmail,posfix※,sendmail
遠程撥號：openvpn※,pptp,openswan※,ipip※
統一認證：openldap(可結合微軟活動目錄)※
隊列工具：ActiveMQ,RabbitMQ※,Metaq,MemcacheQ,Zeromq
打包發布：mvn※,ants※,jenkins※,svn
測試軟體：ab,smokeping,siege,JMeter,Webbench,LoadRunner,http_load（都是※）
日誌相關：syslog,rsyslog,Awstats,flume logstash scribe kafka,storm，ELK(Elasticsearch+Logstash+Kibana)DB代理：mysql-proxy,amoeba（更多還是程序實現讀寫分離）
搜索軟體：Sphinx,Xapian（大公司會自己開發類似網路的小規模內部搜索引擎）

提示：
1）以上所有軟體都是老男孩用過或測試過的。
2）帶※的為老男孩最近幾年用的比較多，可信任使用的。也是近年來linux運維的大眾。
3）有了功能分類和軟體名，大家有需求，可以按功能找軟體直接G就知道了。
4）學習要有舍有得，什麼都抓必然短時間都不會精，希望大家能抓重點，抓精髓，大眾軟體（帶※）先熟練了，這是基礎加提高，在研究小眾軟體（不帶※），這是高手之路，最後在研究偏門的，世外高手之路，當然前提是先掌握前面的大眾和小眾。
5）當然還有一些沒有大眾開源的有一些也很棒，如審計堡壘機程序。

5. FreeBSD做伺服器的好處是什麼比較WIN和LINUX的區別.

穩定、安全、性能的綜合選擇，如果你認為伺服器的最重要指標不只是速度快，那麼FreeBSD一定會讓你充滿驚喜，FBI的伺服器就用FreeBSD。下面是的壓力測試（下載大圖查看）

測試環境：均在虛擬機環境下，不和真機對比測試。其它沒說明的信息均代表一致，軟體的安裝均使用包管理方式，沒使用源代碼安裝，系統沒做任何調優。3個虛擬伺服器同時打開，每測試一個伺服器均測試兩次，以最好的結果為准。（測試結果順序：FreeBSD、Ubuntu、Win2019）。注意：nginx伺服器版本沒統一，會稍微影響結果的公平性，但在合理范圍之內。

ab重要指標：Requests per second（越大越好）、Time per request（越小越好）、Transfer rate（越大越好，大流量下的吞吐量）

結論：FreeBSD在大壓力情況下的性能要比ubuntu略好，穩定性、安全性、健壯性也要比Linux好。當然如果要是用於深度學習而不是web，我可能會選Linux。

另外，安全都是相對的，雖然默認情況下*BSD比Linux安全，但並不代表你維護起來就安全，賬號密碼、ssh安全，許可權，web程序的安全，都會影響系統安全性（web站點還是推薦使用wordpress最新版，安全插件使用：WP Cerber Security，比All In One WP Security略好，但即使剛入門，也比windows經常打補丁放心的多。只是FreeBSD調試wordpress還需要提高更多的技術，不是簡單的pkginstall就完了，需要對nginx、php、mysql有足夠的掌握，這些看起來復雜，但會了又覺得其樂無窮，而且絕對會培養起傳統黑客的精神和體會到簡潔的強大。

6. nginx比apache處理靜態文件速度快，但是nginx處理大量並發的php請求時，容易出現502錯誤，頻率大概是多少

為什麼Nginx的性能要比Apache高得多？

這得益於Nginx使用了最新的epoll（Linux2.6內核）和kqueue（freebsd）網路I/O模型，而Apache則使用的是傳統的select模型。目前Linux下能夠承受高並發訪問的Squid、Memcached都採用的是epoll網路I/O模型。
處理大量的連接的讀寫，Apache所採用的select網路I/O模型非常低效。下面用一個比喻來解析Apache採用的select模型和Nginx採用的epoll模型進行之間的區別：
假設你在大學讀書，住的宿舍樓有很多間房間，你的朋友要來找你。select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。而epoll版宿管大媽會先記下每位同學的房間號，你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。如果來了10000個人，都要找自己住這棟樓的同學時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高並發伺服器中，輪詢I/O是最耗時間的操作之一，select和epoll的性能誰的性能更高，同樣十分明了。

為什麼會出現502錯誤呢？

nginx出現502有很多原因，但大部分原因可以歸結為資源數量不夠用，也就是說後端php-fpm處理有問題，nginx將正確的客戶端請求發給了後端的php-fpm進程，但是因為php-fpm進程的問題導致不能正確解析php代碼，最終返回給了客戶端502錯誤。優化php-fpm，優化代碼，加大內存才是解決502的根源。

10000並發的話，nginx的表現怎麼樣？

2009年9月3日下午2：30，金山游戲《劍俠情緣網路版叄》臨時維護1小時，大量玩家上官網，論壇、評論、客服等動態應用Nginx伺服器集群，每台伺服器的Nginx活動連接數達到2.8萬。