A. 問下pageadmin cms自助建站系統如何操作簡單么
1、多語言、多站點：後台可以任意增加分站，每個分站可以任意設置語種，分站之間的信息可以靈活調用，可以靈活設置管理員單獨管理分站。
方便靈活的欄目管理：後台可以對欄目進行任意增加，修改和刪除，並可以無限級增加子欄目。
強大的信息發布功能：支持信息的發布，刪除，修改，復制，轉移，可自由設置置頂，最新，熱門，審核等屬性，管理員可以在後台發布信息，同時支持匿名投稿及會員中心投稿，會員可以在會員中心管理自己發布的信息。
2、自定義表單+自定義欄位+自定義模型：通過後台可以任意增加表單，如系統自帶的文章，圖片，下載，留言，招聘等板塊都通過此功能來實現；欄位可以任意 增加和修改，支持常用文本欄位，下拉欄位，圖片及圖片組欄位，附件及附件組欄位；用戶可以通過此功能實現任何個性化的功能及展示需求。
完善的SEO優化功能，後台可以生成靜態，每個靜態文件名，目錄都可以自由設置，任意頁面可以自定義標題，關鍵詞，描述。
工作流：可以自定義信息發布的流程，比如前台投稿，需要A用戶審核後轉給b用戶審核，在轉給c用戶審核。
3、計劃任務功能：如果需要某個功能在特定時間定期執行就可以利用此功能，可以支持循環支持，可以按月，按天，按小時來設置執行時間。
信息簽收功能：比如我們發布一篇文章，需要特定用戶或特定用戶組簽收就可以用此功能，支持單用戶，用戶組或按部門來簽收。
信息簽發功能：信息審核員可以在後台或會員中心對信息進行簽發和審核，支持按工作流來簽發，簽發後方通過審核、並顯示在網站上。
4、在線支付功能：支持支付寶，財務通，網銀在線等介面，馬上支付，即時入賬。
在線訂購功能：用戶可以對產品進行在線下單，支持訂單刪除，修改及支付等商務性功能。
信息發送：支持站內信息，郵件，手機簡訊三種發送方式，可以進行單用戶發送，會員組和指定用戶群發。
採集功能：採用ajax方式進行採集，可以遠程圖片保存到本地，可以過濾特定字元，特定url等。
1、簡單易用、強大靈活：以前開發一個網站只能找網路公司， 做出的網站管理後台功能簡單，導致後期維護、修改和擴展困難，甚至只能付費讓製作公司維護，PageAdmin強大的功能、易用性、靈活擴展性完美的解決 了這些問題。因為系統經過多年發展，其間綜合了大量用戶的切身使用體驗，大大小小經過上百次的升級更新，在操作上不斷追求人性化，功能上在也日趨完善，其 中的自定義表單+自定義模型功能更是讓用戶可以輕松開發出自己的個性化功能。
2
2、高負載功能：一個網站負載功能在網站訪問量或內容量巨大時至關重要，pageadmin通過生成靜態化和資料庫連接優化兩個方面來提高網站的負載能力。
樣式和內容分離：系統主體框架div+css結構，遵循國際最新W3C網頁設計標准，兼容IE系列、火狐等主流瀏覽器，內容和樣式分離讓網站風格可以輕松修改和更換，而不會導致內容和結構的破壞。
3
3、周密的安全策略和攻擊防護：對SQL參數進行敏感字元過濾、對密碼、cookie進行了不可逆加密處理，資料庫備份功能、對管理員許可權的自由分配等，在方方面面保證了系統的安全和穩定。
PageAdmin建站系統特點：
B. 網站性能優化怎麼辦
一、前端優化
網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。
首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、Javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：
對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：
1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。
對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。
2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。
3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。
4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。
5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。
對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。
1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。
要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。
我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。
2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。
3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。
4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問www.xxx.com，伺服器會通過301轉向到www.xxx.com/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。
還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。
做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。
當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。
二、後端優化
上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。
前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：
1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： http://www.mysqlperformanceblog.com/），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。
2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的免費php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，還有收費的Zend Performance Suite
3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。
4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。
5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。
6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能
7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構
最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。
C. 伺服器負載量過大，怎樣處理
一，確認伺服器硬體是否足夠支持當前的流量。
二，優化資料庫訪問。
伺服器的負載過大，一個重要的原因是CPU負荷過大，降低伺服器CPU的負荷，才能夠有效打破瓶頸。而使用靜態頁面可以使得CPU的負荷最小化。前台實現完全的靜態化當然最好，可以完全不用訪問資料庫，不過對於頻繁更新的網站，靜態化往往不能滿足某些功能。
緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問資料庫，WordPress和Z-Blog都大量使用這種緩存技術。
如果確實無法避免對資料庫的訪問，那麼可以嘗試優化資料庫的查詢SQL.避免使用Select *from這樣的語句，每次查詢只返回自己需要的結果，避免短時間內的大量SQL查詢。
三，禁止外部的盜鏈。
外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控制盜鏈，Apache自己就可以通過配置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現同樣的功能。當然，偽造refer也可以通過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。
四，控制大文件的下載。
大文件的下載會佔用很大的流量，並且對於非SCSI硬碟來說，大量文件下載會消耗CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一台伺服器上。
D. 如何配置Web伺服器實現負載均衡
網路的負載均衡是一種動態均衡技術，通過一些工具實時地分析數據包，掌握網路中的數據流量狀況，把任務合理均衡地分配出去。這種技術基於現有網路結構，提供了一種擴展伺服器帶寬和增加伺服器吞吐量的廉價有效的方法，加強了網路數據處理能力，提高了網路的靈活性和可用性。
以四台伺服器為例實現負載均衡：
安裝配置LVS
1. 安裝前准備：
(1)首先說明，LVS並不要求集群中的伺服器規格劃一，相反，可以根據伺服器的不同配置和負載狀況，調整負載分配策略，充分利用集群環境中的每一台伺服器。如下表：
Srv Eth0 Eth0：0 Eth1 Eth1：0
vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254
vsbak 10.0.0.3 192.168.10.102
real1 192.168.10.100
real2 192.168.10.101
其中，10.0.0.2是允許用戶訪問的IP。
(2)這4台伺服器中，vs1作為虛擬伺服器(即負載平衡伺服器)，負責將用戶的訪問請求轉發到集群內部的real1，real2，然後由real1，real2分別處理。
Client為客戶端測試機器，可以為任意操作系統。
(3)所有OS為redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch過ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 網段是24 位。
2.理解LVS中的相關術語
(1) ipvsadm ：ipvsadm是LVS的一個用戶界面。在負載均衡器上編譯、安裝ipvsadm。
(2) 調度演算法： LVS的負載均衡器有以下幾種調度規則：Round-robin，簡稱rr;weighted
Round-robin，簡稱wrr;每個新的連接被輪流指派到每個物理伺服器。Least-connected，簡稱lc;weighted
Least-connected，簡稱wlc，每個新的連接被分配到負擔最小的伺服器。
(3) Persistent client
connection，簡稱pcc，(持續的客戶端連接，內核2.2.10版以後才支持)。所有來自同一個IP的客戶端將一直連接到同一個物理伺服器。超時時間被設置為360秒。Pcc是為https和cookie服務設置的。在這處調度規則下，第一次連接後，所有以後來自相同客戶端的連接(包括來自其它埠)將會發送到相同的物理伺服器。但這也會帶來一個問題，因為大約有25%的Internet
可能具有相同的IP地址。
(4) Persistent port
connection調度演算法：在內核2.2.12版以後，pcc功能已從一個調度演算法(你可以選擇不同的調度演算法：rr、wrr、lc、wlc、pcc)演變成為了一個開關選項(你可以讓rr、
wrr、lc、wlc具備pcc的屬性)。在設置時，如果你沒有選擇調度演算法時，ipvsadm將默認為wlc演算法。 在Persistent port
connection(ppc)演算法下，連接的指派是基於埠的，例如，來自相同終端的80埠與443埠的請求，將被分配到不同的物理伺服器上。不幸的是，如果你需要在的網站上採用cookies時將出問題，因為http是使用80埠，然而cookies需要使用443埠，這種方法下，很可能會出現cookies不正常的情況。
(5)Load Node Feature of Linux Director：讓Load balancer 也可以處理users 請求。
(6)IPVS connection synchronization。
(7)ARP Problem of LVS/TUN and LVS/DR：這個問題只在LVS/DR，LVS/TUN 時存在。
3. 配置實例
(1) 需要的軟體包和包的安裝：
I. piranha-gui-0.4.12-2*.rpm (GUI介面cluster設定工具);
II. piranha-0.4.12-2*.rpm;
III. ipchains-1.3.9-6lp*.rpm (架設NAT)。
取得套件或mount到光碟，進入RPMS目錄進行安裝:
# rpm -Uvh piranha*
# rpm -Uvh ipchains*
(2) real server群：
真正提供服務的server(如web
server)，在NAT形式下是以內部虛擬網域的形式，設定如同一般虛擬網域中Client端使用網域：192.168.10.0/24
架設方式同一般使用虛擬IP之區域網絡。
a. 設網卡IP
real1 ：192.168.10.100/24
real2 ：192.168.10.101/24
b.每台server均將default gateway指向192.168.10.254。
192.168.10.254為該網域唯一對外之信道，設定在virtual server上，使該網域進出均需通過virtual server 。
c.每台server均開啟httpd功能供web server服務，可以在各real server上放置不同內容之網頁，可由瀏覽器觀察其對各real
server讀取網頁的情形。
d.每台server都開啟rstatd、sshd、rwalld、ruser、rsh、rsync，並且從Vserver上面拿到相同的lvs.conf文件。
(3) virtual server：
作用在導引封包的對外主機，專職負責封包的轉送，不提供服務，但因為在NAT型式下必須對進出封包進行改寫，所以負擔亦重。
a.IP設置：
對外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2
對內eth1：192.168.10.1 eth1：0 ：192.168.10.254
NAT形式下僅virtual server有真實IP，real server群則為透過virtual server.
b.設定NAT功能
# echo 1 >; /proc/sys/net/ipv4/ip_forward
# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag
# ipchains -P forward MASQ
c.設定piranha 進入X-window中 (也可以直接編輯/etc/lvs.cf )
a).執行面板系統piranha
b).設定「整體配置」(Global Settings) 主LVS伺服器主機IP：10.0.0.2， 選定網路地址翻譯(預設) NAT路徑名稱：
192.168.10.254， NAT 路徑裝置： eth1：0
c).設定虛擬伺服器(Virtual Servers) 添加編輯虛擬伺服器部分：(Virtual
Server)名稱：(任意取名);應用：http;協議： tcp;連接：80;地址：10.0..0.2;裝置：eth0：0; 重入時間：180
(預設);服務延時：10 (預設);載入監控工具：ruptime (預設);調度策略：Weighted least-connections; 持續性：0
(預設); 持續性屏蔽： 255.255.255.255 (預設); 按下激活：實時伺服器部分：(Real Servers); 添加編輯：名字：(任意取名);
地址： 192.168.10.100; 權重：1 (預設) 按下激活
另一架real server同上，地址：192.168.10.101。
d). 控制/監控(Controls/Monitoring)
控制：piranha功能的激活與停止，上述內容設定完成後即可按開始鍵激活piranha.監控器：顯示ipvsadm設定之routing table內容
可立即更新或定時更新。
(4)備援主機的設定(HA)
單一virtual server的cluster架構virtual server 負擔較大，提供另一主機擔任備援，可避免virtual
server的故障而使對外服務工作終止;備份主機隨時處於預備狀態與virtual server相互偵測
a.備份主機：
eth0： IP 10.0.0.3
eth1： IP 192.168.10.102 同樣需安裝piranha，ipvsadm，ipchains等套件
b.開啟NAT功能(同上面所述)。
c.在virtual server(10.0.0.2)主機上設定。
a).執行piranha冗餘度 ;
b).按下「激活冗餘度」;
冗餘LVS伺服器IP： 10.0.0.3;HEARTBEAT間隔(秒數)： 2 (預設)
假定在…秒後進入DEAD狀態： 5 (預設);HEARTBEAT連接埠： 539 (預設)
c).按下「套用」;
d).至「控制/監控」頁，按下「在當前執行層添加PULSE DEAMON」 ，按下「開始」;
e).在監控器按下「自動更新」，這樣可由窗口中看到ipvsadm所設定的routing table，並且動態顯示real
server聯機情形，若real server故障，該主機亦會從監視窗口中消失。
d.激活備份主機之pulse daemon (執行# /etc/rc.d/init.d/pulse start)。
至此，HA功能已經激活，備份主機及virtual server由pulse daemon定時相互探詢，一但virtual
server故障，備份主機立刻激活代替;至virtual server 正常上線後隨即將工作交還virtual server。
LVS測試
經過了上面的配置步驟，現在可以測試LVS了，步驟如下：
1. 分別在vs1，real1，real2上運行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目錄是vs2輸出的。如果您的NFS配置沒有成功，也可以把vs1上/etc/lvs/rc.lvs_dr復制到real1，real2上，然後分別運行。確保real1，real2上面的apache已經啟動並且允許telnet。
2. 測試Telnet：從client運行telnet 10.0.0.2，
如果登錄後看到如下輸出就說明集群已經開始工作了：(假設以guest用戶身份登錄)
[guest@real1 guest]$——說明已經登錄到伺服器real1上。
再開啟一個telnet窗口，登錄後會發現系統提示變為：
[guest@real2 guest]$——說明已經登錄到伺服器real2上。
3. 測試http：從client運行iexplore http://10.0.0.2
因為在real1 和real2 上面的測試頁不同，所以登錄幾次之後，顯示出的頁面也會有所不同，這樣說明real server 已經在正常工作了。
E. 海量高並發處理網站的負載均衡如何設計
Ｈ綣�蘊�鍾猩璞溉プ鯰布��叮��斐勺試吹睦朔眩��胰綣�院竺媼僖滴窳康募ぴ觶�植壞貌輝俅瓮度敫叨畹撓布��凍殺荊�踔列閱茉僮吭降納璞敢膊荒藶�憬�匆滴窳康男棖蟆� 在此種情況下，單純的網路架構就顯得捉襟見肘了，而負載均衡機制則應運而生。 伺服器負載均衡(Server Load Balancing)，其原理是將工作任務相對均衡地分攤到多個節點(伺服器集群)上執行，從而提升整個業務系統的性能。諸如LVS、HA Proxy等開源軟體，可以在現有的網路基礎架構之上建立負載均衡機制，以滿足業務增長的需要，對於網站的來說不啻為一種廉價且有效的擴展性選擇。 此外，針對互聯網上有可能影響數據傳輸的各種環節，CDN(Content Delivery Network)內容交付網路的應對方案也適時出現。CDN對網站內容的處理，主要在於利用緩存技術將靜態內容快速分發至邊緣節點，通過讓用戶就近取得所需內容，解決 Internet網路擁擠的狀況，提高用戶訪問網站的響應速度，同時也減輕了網站自身系統的性能壓力。 現在看來，貌似我們已經解決了網站發布所面臨的所有瓶頸了，但是實際上問題遠沒有那麼簡單。一方面，對於數據交互比較頻繁的動態內容而言，CDN只能在其中心節點與源數據節點(網站自身系統)之間做有限的傳輸優化，加速效果遠不如靜態內容做緩存分發那般明顯。 另一方面，隨著線上業務、電子商務等領域的Web內容呈現日漸豐富，涌現出了愈發復雜的業務交付需求，這對網站的發布方而言也意味著將面臨更多的挑戰。因此，當我們拋開網路的傳輸質量、帶寬擁塞程度等外界因素來看的話，又不得不正視一個問題--影響網站訪問效果的最大瓶頸還是在於源數據節點自身的處理性能。 以電子商務網站這種典型的大型高並發訪問量的線上業務為例，其性能瓶頸最容易出現在聯機事務處理(OLTP)的環節，例如訪問用戶進行條目查閱、訂單確認等場景。產生這種情況的原因在於，網站的運營方出於數據安全等因素的考慮，是不可能將後台資料庫等資源完全向CDN服務商開放的。由此造成，所有涉及到此類動態資源的訪問就會頻繁地經由CDN網路的邊緣節點上溯到源數據節點(即網站自身系統)來請求實時地響應處理。在保障數據安全性的前提下，要解決網站的性能瓶頸問題，必須提高源數據節點的業務處理效率，因此我們還得從網路架構的設計著手。 前文提到過，單台伺服器的處理能力有限，當突發訪問量驟然增加的時候，其性能就會成為整個系統的瓶頸，導致用戶訪問的響應緩慢甚至網站伺服器癱瘓。為了滿足高並發量訪問的需求，可以通過軟體手段實現伺服器集群的多機負載均衡效果。然而，這種軟體式的負載均衡有一個不可避免的缺點，那便是系統的穩定性和性能方面受限於軟體所安裝運行的伺服器，一旦訪問量過大時，該台伺服器就恰恰成了整個系統的瓶頸所在。 就一個發布線上業務的網站系統而言，前台的Web伺服器由於有外部的CDN服務作為靜態內容的分流渠道，尚不至於產生明顯的系統瓶頸，而後台處理動態內容的核心業務系統就難免會感到壓力巨大了。具體分析的話，當前的業務系統多採用客戶端--中間件--資料庫的三層結構設計，通常多是利用WebLogic中間件軟體自帶的伺服器集群功能來滿足高性能需求，其中一台WebLogic Server作為管理伺服器負責任務調度，實現負載均衡效果。但是，當訪問用戶到達一定數目的時候，由於該伺服器自身的硬體性能瓶頸，會造成整個系統的聯機事務處理效率低下;而且由於WebLogic自身設計的原因，當任務量達到一定閥值的時候，即便是升級伺服器硬體性能也無法提升其進行負載均衡調度的能力。 針對上述情況，最好的辦法莫過於採用硬體負載均衡設備，以解決數據流量過大、任務負荷過重所產生的系統瓶頸問題。在這一方面，業內知名的硬體廠商有F5、深信服等等。值得一提的是，深信服的應用交付產品除具有傳統負載均衡功能外，其獨有的單邊加速技術，能夠在跨運營商網路環境中，通過廣域網傳輸文件及應用的訪問時間減少30%以上，極大提高了用戶體驗。 雖然部署硬體設備意味著一筆額外的開支，但是它給網站的整體業務系統所帶來的性能提升，卻是傳統的軟體方案所望其項背的。除此之外，專業的硬體設備所能提供的負載調度演算法和健康檢查機制也更加豐富、全面，有助於進一步提升關鍵業務發布的穩定性和持久性，這對於高並發量的大型網站而言是極具價值的。 當然，對於不同規模、不同業務的網站而言，沒有一概而論的設計標准，文中提到的技術手段都有著相應的適用場景，這就需要網站的架構師們做具體的規劃了。
F. 如何進行網站性能優化
一、前端優化
網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。
首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、Javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：
對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：
1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。
對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。
2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。
3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。
4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。
5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。
對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。
1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。
要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。
我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。
2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。
3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。
4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問，伺服器會通過301轉向到/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。
還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。
做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。
當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。
二、後端優化
上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。
前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：
1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： ），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。
2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ ）、php accelebrator()，還有收費的Zend Performance Suite
3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。
4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。
5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。
6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能
7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構
最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。
G. 多台伺服器如何做網路負載均衡
1：找分區或目錄同步軟體，某台伺服器改動了自動把修改應用到別的伺服器，比如紅旗的HA。
2：換種建伺服器的思路，後台用一台獨立的伺服器做資料庫和文件伺服器，用來存放資料庫和上傳的文件，另外的做負載均衡運行伺服器，把不需要變動的網頁程序放上面。