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

　　

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