【導(dǎo)讀】由于自己正在做一個(gè)高性能大用戶(hù)量的論壇程序，對(duì)高性能高并發(fā)服務(wù)器架構(gòu)比較感興趣，于是在網(wǎng)上收集了不少這方面的資料和大家分享。希望能和大家交流。談?wù)劥笮透哓?fù)載網(wǎng)站服務(wù)器的優(yōu)化心得!瀏覽量比較大的網(wǎng)站應(yīng)該從哪幾個(gè)方面入手？

　　

【正文】 量使用虛擬內(nèi)存），還是磁盤(pán) I/O 性能跟不上（硬盤(pán)指示燈狂閃）？這幾個(gè)都是可以通過(guò)升級(jí)硬件來(lái)解決或者改善的（使用更高等級(jí)的 CPU，更快速和更大容量的內(nèi)存，配置硬件磁盤(pán)陣列并使用更多數(shù)量的高速 SCSI 硬盤(pán)），但這需要較大的投入。 軟件方面，如果使用了更大容量的內(nèi)存和改善的 I/O 性能，已經(jīng)能夠大幅提高數(shù)據(jù)庫(kù)的運(yùn)行效率，還可以配置查詢(xún)緩存和進(jìn)一步優(yōu)化數(shù)據(jù)庫(kù)結(jié)構(gòu)和查詢(xún)語(yǔ)句，就能讓數(shù)據(jù)庫(kù)的性能再進(jìn)一大步。 如果在服務(wù)器硬件投入上有困 難，那就盡量生成靜態(tài)頁(yè)面。 作 者 : BBSADM 標(biāo) 題 : 目前的 web 系統(tǒng)架構(gòu) 時(shí) 間 : Fri Apr 6 20:15:56 2020 點(diǎn) 擊 : 100 nginx | | | Squid fastcgi proxy | (逐步遷移 ) | 靜態(tài)文件 Njuwebbsd (逐步遷移到 fastcgi 上 ) 最大好處是靜態(tài)文件加速。 以后準(zhǔn)備把帖子內(nèi)容也靜態(tài)化，實(shí)現(xiàn)最低負(fù)荷 而且用 nginx 做前臺(tái)便于負(fù)載均衡，測(cè)試機(jī)可以拿來(lái)做靜態(tài)文件的負(fù)載均衡 ? 初創(chuàng)網(wǎng)站與開(kāi)源軟件 前面有一篇文章中提到過(guò)開(kāi)源軟件，不過(guò)主要是在系統(tǒng)運(yùn)維的角度去講的，主要分析一些系統(tǒng)級(jí)的開(kāi)源軟件 (例如 bind,memcached)，這里我們討論的是用于搭建初創(chuàng)網(wǎng)站應(yīng)用的開(kāi)源軟件 (例如 phpbb,phparticle)，運(yùn)行在 Linux， MySQL， Apache,PHP,Java 等下面。 創(chuàng)業(yè)期的網(wǎng)站往往采用比較簡(jiǎn)單的系統(tǒng)架構(gòu)，或者是直接使用比較成熟的開(kāi)源軟件。使用開(kāi)源軟件的好處是搭建速度快，基本不需要開(kāi)發(fā)，買(mǎi)個(gè)空間域名，下個(gè)軟件一搭建，用個(gè)半天就搞定了，一個(gè)嶄新的網(wǎng)站就開(kāi)張了，在前期可以極大程度的節(jié)約時(shí)間成本和開(kāi)發(fā)成本。 當(dāng)然使用開(kāi)源軟件搭建應(yīng)用也存在一些局限性，這是我們要重點(diǎn)研究的，而研究的目的就是如何在開(kāi)源軟件選型時(shí)以及接下來(lái)的維護(hù)過(guò)程中盡量避免。 一方面是開(kāi)源軟件一般只有在比較成熟的領(lǐng)域 才有，如果是一些創(chuàng)新型的項(xiàng)目很難找到合適的開(kāi)源軟件，這個(gè)時(shí)候沒(méi)什么好的解決辦法，如果非要用開(kāi)源的話一般會(huì)找一個(gè)最相似的改一下。實(shí)際上目前開(kāi)源的項(xiàng)目也比較多了，在 上可以找到各種各樣的開(kāi)源項(xiàng)目。選型的時(shí)候盡量應(yīng)該選取一個(gè)程序架構(gòu)比較簡(jiǎn)單的，不一定越簡(jiǎn)單越好，但一定要簡(jiǎn)單，一目了然，別用什么太高級(jí)的特性，互聯(lián)網(wǎng)應(yīng)用項(xiàng)目不需要太復(fù)雜的框架。原因有兩個(gè)，一個(gè)是框架復(fù)雜無(wú)非是為了實(shí)現(xiàn)更好的可擴(kuò)展性和更清晰的層次，而我們正在做的互聯(lián)網(wǎng)應(yīng)用范圍一般會(huì)比開(kāi)源軟件設(shè)計(jì)時(shí)所考慮的范圍小的多，所以有的應(yīng)用會(huì)顯得設(shè)計(jì)過(guò)度 ，另外追求完美的層次劃分導(dǎo)致的太復(fù)雜的繼承派生關(guān)系也會(huì)影響到整個(gè)系統(tǒng)維護(hù)的工作量。建議應(yīng)用只需要包含三個(gè)層就可以了，數(shù)據(jù) (實(shí)體 )層，業(yè)務(wù)邏輯層，表現(xiàn)層。太復(fù)雜的設(shè)計(jì)容易降低開(kāi)發(fā)效率，提高維護(hù)成本，在出現(xiàn)性能問(wèn)題或者突發(fā)事件的時(shí)候也不容易找到原因。 另外一個(gè)問(wèn)題是開(kāi)源軟件的后期維護(hù)和繼續(xù)開(kāi)發(fā)可能會(huì)存在問(wèn)題，這一點(diǎn)不是絕對(duì)的，取決于開(kāi)源軟件的架構(gòu)是否清晰合理，擴(kuò)展性好，如果是較小的改動(dòng)可能一般不會(huì)存在什么問(wèn)題，例如添加一項(xiàng)用戶(hù)屬性或者文章屬性，但有些需求可能就不是很容易實(shí)現(xiàn)了。例如網(wǎng)站發(fā)展到一定階段后可能會(huì)考慮 擴(kuò)展產(chǎn)品線，原來(lái)只提供一個(gè)論壇加上 cms，現(xiàn)在要再加上商城，那用戶(hù)系統(tǒng)就會(huì)有問(wèn)題，如何解決這個(gè)問(wèn)題已經(jīng)不僅僅是改一下論壇或者 cms 就可以解決了，這個(gè)時(shí)候我們需要上升到更高的層次來(lái)考慮問(wèn)題，是否需要建立針對(duì)整個(gè)網(wǎng)站的用戶(hù)認(rèn)證系統(tǒng)，實(shí)現(xiàn)單點(diǎn)登錄，用戶(hù)可以在產(chǎn)品間無(wú)縫切換而且保持登錄狀態(tài)。由于網(wǎng)站初始的用戶(hù)數(shù)據(jù)可能大部分都存放在論壇里，這個(gè)時(shí)候我們需要把用戶(hù)數(shù)據(jù)獨(dú)立出來(lái)就會(huì)碰到麻煩，如何既能把用戶(hù)數(shù)據(jù)獨(dú)立出來(lái)又不影響論壇原有系統(tǒng)的繼續(xù)運(yùn)行會(huì)是件很頭痛的事情。經(jīng)過(guò)一段時(shí)間的運(yùn)行，除非是特別好的設(shè)計(jì)以及比較好的維護(hù)， 一般都會(huì)在論壇里存在各種各樣亂七八糟的對(duì)用戶(hù)信息的調(diào)用，而且是直接針對(duì)數(shù)據(jù)庫(kù)的，這樣如果要將用戶(hù)數(shù)據(jù)移走的話要修改代碼的工作量將不容忽視，而另外一個(gè)解決辦法是復(fù)制一份用戶(hù)數(shù)據(jù)出來(lái)，以新的用戶(hù)數(shù)據(jù)庫(kù)為主，論壇里的用戶(hù)數(shù)據(jù)通過(guò)同步或異步的機(jī)制實(shí)現(xiàn)同步。最好的解決辦法就是在選型時(shí)選一個(gè)數(shù)據(jù)層封裝的比較好的， sql 代碼不要到處飛的軟件，然后在維護(hù)的時(shí)候保持系統(tǒng)原有的優(yōu)良風(fēng)格，把所有涉及到數(shù)據(jù)庫(kù)的操作都放到數(shù)據(jù)層或者實(shí)體層里，這樣無(wú)論對(duì)數(shù)據(jù)進(jìn)行什么擴(kuò)展，代碼修改起來(lái)都比較方便，基本不會(huì)對(duì)上層的代碼產(chǎn)生影響。 網(wǎng)站訪問(wèn) 速度問(wèn)題對(duì)初創(chuàng)網(wǎng)站來(lái)說(shuō)一般考慮的比較少，買(mǎi)個(gè)空間或者托管服務(wù)器，搭建好應(yīng)用后基本上就開(kāi)始運(yùn)轉(zhuǎn)了，只有到真正面臨極大的速度訪問(wèn)瓶頸后才會(huì)真正對(duì)這個(gè)問(wèn)題產(chǎn)生重視。實(shí)際上在從網(wǎng)站的開(kāi)始階段開(kāi)始，速度問(wèn)題就會(huì)一直存在，并且會(huì)隨著網(wǎng)站的發(fā)展也不斷演進(jìn)。一個(gè)網(wǎng)站最基本的要求，就是有比較快的訪問(wèn)速度，沒(méi)有速度，再好的內(nèi)容或服務(wù)也出不來(lái)。所以，訪問(wèn)速度在網(wǎng)站初創(chuàng)的時(shí)候就需要考慮，無(wú)論是采用開(kāi)源軟件還是自己開(kāi)發(fā)都需要注意，數(shù)據(jù)層盡量能夠正確，高效的使用 SQL。 SQL 包含的語(yǔ)法比較復(fù)雜，實(shí)現(xiàn)同樣一個(gè)效果如果考慮到應(yīng)用層的的不同 實(shí)現(xiàn)方法，可能有好幾種方法，但里面只有一種是最高效的，而通常情況下，高效的 SQL 一般是那個(gè)最簡(jiǎn)單的 SQL。在初期這個(gè)問(wèn)題可能不是特別明顯，當(dāng)訪問(wèn)量大起來(lái)以后，這個(gè)可能成為最主要的性能瓶頸，各種雜亂無(wú)章的 SQL會(huì)讓人看的瘋掉。當(dāng)然前期沒(méi)注意的話后期也有解決辦法，只不過(guò)可能不會(huì)解決的特別徹底，但還是要吧非常有效的提升性能?？?MySQL 的 SlowQuery Log 是一個(gè)最為簡(jiǎn)便的方法，把執(zhí)行時(shí)間超過(guò) 1 秒的查詢(xún)記錄下來(lái)，然后分析，把該加的索引加上，該簡(jiǎn)單的 SQL 簡(jiǎn)化。另外也可以通過(guò) Showprocesslist 查看 當(dāng)前數(shù)據(jù)庫(kù)服務(wù)器的死鎖進(jìn)程，從而鎖定導(dǎo)致問(wèn)題的SQL 語(yǔ)句。另外在數(shù)據(jù)庫(kù)配置文件上可以做一些優(yōu)化，也可以很好的提升性能，這些文章在網(wǎng)站也比較多，這里就不展開(kāi)。 這些工作都做了以后，下面數(shù)據(jù)庫(kù)如果再出現(xiàn)性能問(wèn)題就需要考慮多臺(tái)服務(wù)器了，一臺(tái)服務(wù)器已經(jīng)解決不了問(wèn)題了，我以前的文章中也提到過(guò)，這里也不再展開(kāi)。 其它解決速度問(wèn)題的辦法就不僅僅是在應(yīng)用里面就可以實(shí)現(xiàn)的了，需要從更高的高度去設(shè)計(jì)系統(tǒng)，考慮到服務(wù)器，網(wǎng)絡(luò)的架構(gòu)，以及各種系統(tǒng)級(jí)應(yīng)用軟件的配合，這里也不再展開(kāi)。 良好設(shè)計(jì)并實(shí)現(xiàn)的應(yīng)用 +中間件 +良好的分布式設(shè)計(jì)的數(shù) 據(jù)庫(kù) +良好的系統(tǒng)配置 +良好的服務(wù)器 /網(wǎng)絡(luò)結(jié)構(gòu)，就可以支撐起一個(gè)較大規(guī)模的網(wǎng)站了，加上前面的幾篇文章，一個(gè)小網(wǎng)站發(fā)展到大網(wǎng)站的過(guò)程基本上就齊了。這個(gè)過(guò)程會(huì)是一個(gè)充滿(mǎn)艱辛和樂(lè)趣的過(guò)程，也是一個(gè)可以逐漸過(guò)渡的過(guò)程，主動(dòng)出擊，提前考慮，減少救火可以讓這個(gè)過(guò)程輕松一些。 ? 談?wù)劥笮透哓?fù)載網(wǎng)站服務(wù)器的優(yōu)化心得 ! 因?yàn)楣ぷ鞯年P(guān)系，我做過(guò)幾個(gè)大型網(wǎng)站（書(shū)庫(kù)、證券）的相關(guān)優(yōu)化工作，一般是在世界排行 10004000 以?xún)?nèi)的 ~~ 這些網(wǎng)站使用的程序各不一樣，配置也不盡相同，但是它們有一個(gè)共同的特點(diǎn)，就是使用的是 FREEBSD 系統(tǒng) ，高配置高負(fù)載， PV 值非常高，都是需要用兩臺(tái)以上獨(dú)立主機(jī)來(lái)支持的網(wǎng)站 ~ 我在優(yōu)化及跟蹤的過(guò)程中，開(kāi)始效果也差強(qiáng)人意，也不太理想，后來(lái)通過(guò)閱讀大量資料才慢慢理清了一些思路，寫(xiě)出來(lái)希望給大家有所幫助。 WEB 服務(wù)器配置是 DUAL XEON 以上， 2G內(nèi)存以上， SCSI 硬盤(pán)一塊以上，F(xiàn)REEBSD 以上 ~~ 數(shù)據(jù)庫(kù)服務(wù)器與 WEB 服務(wù)器類(lèi)似 ~~ 書(shū)庫(kù)程序是使用的 jieqi的，論壇是使用的 Discuz!的 apache + php + mysql + zend + 100M 光 纖獨(dú)享帶寬 一定要重新編譯內(nèi)核，根據(jù)自己對(duì)內(nèi)核認(rèn)識(shí)的程度和服務(wù)器的具體配置來(lái)優(yōu)化，記住打開(kāi) SMP，也可以使用 ULE 調(diào)度。 要優(yōu)化系統(tǒng)的值，一般是添加入 /etc/ 里面，要加大內(nèi)核文件并發(fā)數(shù)量及其他優(yōu)化等值。 APACHE 2 使用 perwork 工作模式就可以了，我試過(guò) worker 模式，實(shí)在是差強(qiáng)人意呀。修改 ，加大并發(fā)數(shù)量和關(guān)閉不需要的模塊。因?yàn)閍pache 非常消耗內(nèi)存，盡量輕裝上陣 ~~ 可以適當(dāng)?shù)氖褂瞄L(zhǎng)連接。關(guān)閉日志。 PHP 編譯的時(shí)候，注意要 盡量以實(shí)用為目的加入?yún)?shù)，沒(méi)有用到的堅(jiān)決不加，以免浪費(fèi)系統(tǒng)資源。 ZEND 要使用較小的優(yōu)化等級(jí)， 15 就足夠了， 1023 級(jí)別只會(huì)加重服務(wù)器負(fù)載~ MYSQL 要盡量少使用長(zhǎng)連接，限制為 23 秒即可 ~ 要全部采用手工編譯方式，不要用 ports 安裝，因?yàn)樗鼤?huì)帶上很多你不需要的模塊，切記。 對(duì)于這類(lèi)高負(fù)載高在線人數(shù)的大站，所有優(yōu)化的思路就是把盡可能多的系統(tǒng)資源，提供給 WEB 和 MYSQL 服務(wù)，并且讓這些服務(wù)單個(gè)進(jìn)程可以占用盡可能少的系統(tǒng)資源。如果系統(tǒng)一開(kāi)始大量使用 SWAP，對(duì)于這些服務(wù)器來(lái)說(shuō)，服務(wù)器狀態(tài) 將會(huì)極劇惡化。 長(zhǎng)時(shí)間觀察跟蹤調(diào)試，有什么問(wèn)題盡快解決 ~~ 就想到這些東東，歡迎大家補(bǔ)充 ~~ 夢(mèng)飛 2020/4/25 . 補(bǔ)充我的幾點(diǎn)優(yōu)化： 編譯 Apache PHP MySQL 時(shí)使用 GCC 參數(shù)傳遞對(duì)特定 CPU 進(jìn)行優(yōu)化； 如果網(wǎng)站小文件很多，可以考慮使用 reiserfs 磁盤(pán)系統(tǒng)，提升讀寫(xiě)性能； 如不需要 .htaccess ，則將 Files .htaccess 設(shè)置為 None 對(duì)于 apache 服務(wù)器繁忙，加大內(nèi)存可以解決不少問(wèn)題。 純交互站點(diǎn)， mysql 性能會(huì)是一個(gè)瓶頸。需要長(zhǎng)期跟蹤更改參數(shù)。 ? Ligd+Squid+Apache 搭建高效率 Web 服務(wù)器 davies 發(fā)表于 202099 01:06 | 分類(lèi) : Tech :: Web :: 架構(gòu)原理 Apache 通常是開(kāi)源界的首選 Web服務(wù)器，因?yàn)樗膹?qiáng)大和可靠，已經(jīng)具有了品牌效應(yīng)，可以適用于絕大部分的應(yīng)用場(chǎng)合。但是它的強(qiáng)大有時(shí)候卻顯得笨重，配置文件得讓人望而生畏，高并發(fā)情況下效率不太高。而輕量級(jí)的 Web服務(wù)器 Ligd 卻是后起之秀，其靜態(tài)文件的響應(yīng)能力遠(yuǎn)高于 Apache，據(jù)說(shuō)是 Apache 的 23 倍。 Ligd 的高性能和易用性，足以打動(dòng)我們，在它能夠勝任的領(lǐng)域，盡量用它。 Ligd 對(duì) PHP 的支持也很好，還可以通過(guò) Fastcgi 方式支持其他的語(yǔ)言，比如 Python。 畢竟 Ligd 是輕量級(jí)的服務(wù)器，功能上不能跟 Apache 比，某些應(yīng)用無(wú)法勝任。比如 Ligd還不支持緩存，而現(xiàn)在的絕大部分站點(diǎn)都是用程序生成動(dòng)態(tài)內(nèi)容，沒(méi)有緩存的話即使程序 的效率再高也很難滿(mǎn)足大訪問(wèn)量的需求，而且讓程序不停的去做同一件事情也實(shí)在沒(méi)有意義。首先，Web 程序是需要做緩存處理的，即把反復(fù)使用的數(shù)據(jù)做緩存。即使這樣也還不夠，單單是啟動(dòng)Web 處理程序的代價(jià)就不少，緩存最后生成的靜態(tài)頁(yè)面是必不可少的。而做這個(gè)是 Squid 的強(qiáng)項(xiàng)，它本是做代理的，支持高效的緩存，可以用來(lái)給站點(diǎn)做反向代理加速。把 Squid 放在 Apache或者 Ligd 的前端來(lái)緩存 Web 服務(wù)器生成的動(dòng)態(tài)內(nèi)容，而 Web 應(yīng)用程序只需要適當(dāng)?shù)卦O(shè)置頁(yè)面實(shí)效時(shí)間即可。 即使是大部分內(nèi)容動(dòng)態(tài)生成的網(wǎng)站，仍免不了會(huì)有一些靜態(tài)元素，比如圖片、 JS 腳本、 CSS 等等，將 Squid 放在 Apache 或者 Lig 前端后，反而會(huì)使性能下降，畢竟處理 HTTP 請(qǐng)求是Web 服務(wù)器的強(qiáng)項(xiàng)。而且已經(jīng)存在于文件系統(tǒng)中的靜態(tài)內(nèi)容再在 Squid 中緩存一下，浪費(fèi)內(nèi)存和硬盤(pán)空間。因此可以考慮將 Ligd 再放在 Squid 的前面，構(gòu)成 Ligd+Squid+Apache 的一條處理鏈， Ligd 在最前面，專(zhuān)門(mén)用來(lái)處理靜態(tài)內(nèi)容的請(qǐng)求，把動(dòng)態(tài)內(nèi)容請(qǐng)求 通過(guò) proxy 模塊轉(zhuǎn)發(fā)給 Squid，如果 Squid 中有該請(qǐng)求的內(nèi)容且沒(méi)有過(guò)期，則直接返回給 Ligd。新請(qǐng)求或者過(guò)期的頁(yè)面請(qǐng)求交由 Apache 中 Web 程序來(lái)處理。經(jīng)過(guò) Ligd 和 Squid 的兩級(jí)過(guò)濾， Apache需要處理的請(qǐng)求將大大減少，減少了 Web 應(yīng)用程序的壓力。同時(shí)這樣的構(gòu)架，便于把不同的處理分散到多臺(tái)計(jì)算機(jī)上進(jìn)行，由 Ligd 在前面統(tǒng)一把關(guān)。 在這種架構(gòu)下，每一級(jí)都是可以進(jìn)行單獨(dú)優(yōu)化的，比如 Ligd 可以采用異步 IO 方式， Squid可以啟用內(nèi)存來(lái)緩存， Apache 可以啟用 MPM 等，并且每一級(jí)都可以使用多臺(tái)機(jī)器來(lái)均衡負(fù)載，伸縮性很好。 實(shí)例講解 下面以 和 域下面的幾個(gè)站點(diǎn)為例來(lái)介紹一下此方案的具體做法。 域下有幾個(gè)用 mod_python 實(shí)現(xiàn)的 blog 站點(diǎn) ，幾個(gè) php 的站點(diǎn)，一個(gè) mod_python的小程序 ，以后可能還會(huì)架設(shè)幾個(gè) PHP和 Django 的站點(diǎn)。而服務(wù)器非常弱， CPU為 Celeron 500，內(nèi)存為 PC 100 384M，因此比較關(guān)注 Web 服務(wù)器的效率。這幾個(gè)站點(diǎn)都是采用虛擬主機(jī)方式，開(kāi)在同一臺(tái)機(jī)器的同一個(gè)端口上。 Ligd 服務(wù)于 80 端口， Squid 運(yùn)行在 3128 端口， Apache 運(yùn)行在 81 端口。 Ligd 的配置 多個(gè)域名采用 /var//dom