因爲最近在給VeryCD作山寨站點，這個可是有1G數據庫的真傢伙，可不是wordpress、沒啥人氣的discuz論壇等這種小菜可以比擬的，想必會在一定程度上考驗VPS的性能。之前選VPS那個花錢如流水，買的多個VPS都還沒到期，打算壓榨一下他們的剩餘價值。應用web.py框架的幾臺VPS/Shared Hosting中，一臺rapidxen的128M Xen方案，一臺ramhost的512M Openvz方案，一臺stdyun.com的80M共享空間方案。
測試Xen vs Openvz vs Shared Hosting的性能比， 用ab -n 1028 -c 128 addr來測，以response time（mean）爲基準 ，他們的性能對比大約是0.8:28:6，這麼個懸殊的差別，實在令我驚訝萬分。
stdyun.com是專爲python優化過的共享主機，本身load average比較低，能有6的表現也屬不錯；ramhost就是一個bt，從來沒見過VPS性能那麼猛的，根據我對數據的初步分析這麼個站同時在線萬人也不會有什麼問題；而rapidxen則讓我大跌眼鏡。
誠然應該有相當部分的原因是rapidxen的方案內存比較小的關係，可是人家內存比你更小（80M）的標準雲都表現比它強6倍，這無論如何有點說不過去。而且觀察程序的內存佔用，令人沮喪地發現，xen的內存佔用達到了openvz的兩倍之多，這讓我強烈審視起網上流傳的xen要比openvz好，能徹底利用主機性能的說法。
有了懷疑，就打算真的好好比較一下他們了，所有錯誤的觀念都要摒棄，所有人云亦云都由我而止，Xen和Openvz到底孰優孰劣，真相只有一個，我追求的就是那儘可能無偏的結論。
本文打算從兩個方面來比較Xen和Openvz的性能。第一是理論方面：根據強大的參考文獻1，具體分析兩個架構的優劣。第二是實踐方面：大家一碗水端平了用真實的應用決勝負：既然內存不公平，那我就給你公平。根據參考文獻2的廉價VPS列表，我挑選了Xen的內存512M的，價格最便宜的PhotonVPS（又是16刀，淚奔，做個測試成本真高）。
以下理論中，普通字是我對參考文獻1的粗略翻譯。
一、Openvz和Xen的技術規格分析
1.Xen與Openvz的區別
Xen和Openvz同樣是虛擬化主機技術，區別在於Xen是半虛擬化技術，它並不是一個真正的虛擬機，而是相當於自己運行了一個內核的實例，可以自由的加載內核模塊，虛擬的內存和IO，穩定而且可預測。Openvz則是操作系統級別的虛擬化技術，是底層操作系統上的一層應用，這意味着易於理解和低權重開銷，一般來說也意味着更優的性能。
這裏有一個問題，可以看到實際上openvz因爲免去了大量的公共開銷，理論上來說性能會比xen更好。爲什麼大家都會認爲openvz過分壓榨性能呢？我認爲是因爲openvz配置起來比較靈活，給黑心openvz服務商改低限制的機會。
比如mediatemple，號稱512M內存的dv方案，kmemsize才12M，不瞭解的人看了512M覺得很哈皮啊，可是使用的時候一般這512M能分到你手裏一半就不錯了。此消彼長，所以纔會有xen能更好地利用機器性能的錯覺
2.Openvz的內核模型
首先當OpenVZ的主機說“256MB的保證”，它實際上意味着約232MB的“privvmpages”，14M的“kmemsize”和其他雜項資源。當應用程序調用 malloc（）分配的內存將被添加到“privvmpages”。
當“privvmpages”超過限制，malloc（）將失敗並返回一個NULL。當主機服務器內存用光了，然後虛擬環境下的進程超過“oomguarpages”的將被終止。
OpenVZ的內存管理方法既有問題也有優勢。最大的問題之一是內存容量的應用程序使用的內存和應用程序實際上分配到的內存是不同的，不同的應用程序他們的差別可能會很大。以Java爲例，它通常分配一大塊的內存，但是，它可能只使用一小部分分配的內存。如果privvmpages受限，java會立即停止運行。調整參數可以解決一部分問題，但它處理得絕對沒有Xen來得乾淨利落。事實上，幾乎所有使用內存分配的應用程序都會受OpenVZ這個問題的影響。
/proc/meminfo 本身也有問題。雖然OpenVZ的已經爲內存進行了虛擬，但是用”free”命令依然會返回主機的內存。這樣就會使小內存的openvz的vps無法運行諸如java或者gcc編譯這樣的程序。
OpenVZ的內存模型的優點是， 它容易理解： 你幾乎就只有privvmpages受限。與專用的服務器或Xen的服務器不一樣的是，你的磁盤高速緩存和頁面緩存並不計入您的總內存使用情況。因此，在一個沒有過度銷售的openvz主機上，由於擁有較大冗餘的公共資源，它實際上可能會比同類規格的Xen的VPS表現更佳。
這實際上解答了我關於ramhost爲啥那麼牛叉的疑惑，因爲據我所知ramhost是相當undersale的服務商，從他們的狀態日誌上可以看到，一般inactive內存都在2G以上，所以性能當然強勁了.
3.Xen的內存模型
Xen的系統模型更容易解釋。256MB的Xen的VPS是就像一個256MB的專用服務器-該內存段是預留作VPS專用，沒有其他VPS能夠使用這部分內存，這就像一個真正的專用服務器。
此外，當內存不足時，VPS會使用Swap。一般每個VPS帶有兩倍大小的交換分區，當您的應用需要更多的內存，不常使用的頁面從內存中被換出到交換分區，從而騰出使更多的房間。因此，256MB的Xen的VPS系統實際上共有768MB內存（256MB內存+ 512MB的交換空間），請相信我，交換空間是非常有用的，特別是處理突發的需求高峯時。
這麼說來，Xen是永遠遠優於OpenVZ？不然，你的256MB的VPS理論可以使用高達768MB內存，而實際上內核，高速緩存，緩衝，他們都佔用內存。這部分系統開銷也是可觀的。另外，Swap會嚴重降低性能。
4.穩定性和可預測性
當內存耗盡時，xen和openvz表現大相徑庭。xen會把不常用的內存頁面換入Swap，這將大大降低性能，當Swap也用盡，那麼xen的系統會響應得越來越慢，就像一臺真實的服務器一樣。
而openvz一旦內存用盡，則會突然死亡：開不出新的程序，只能等待系統資源可用。更有甚者，本來運行的好好的程序也可能因爲不斷增長而超過限制，然後突然死亡。這就像開車開到70碼，然後突然撞牆上了，一般會死得很慘。
毫無疑問這點上我傾向於xen技術，可預測，穩定。
5.結論
如果xen和openvz一樣貴，我肯定選xen，因爲可預測性，即使openvz打8折，我還是追求穩定。
有趣的是我雖然看了這篇文章，卻得出了一個截然相反的結論。
不考慮黑心openvz服務商的問題。由於同樣的程序在xen中佔用內存比openvz兩倍還多，xen總是很容易進入swap環節，從而在同樣的配置下一般會性能更低。
對我來說用vps就是追求性價比的。像openvz那樣撞牆？不怕，程序寫寫好，控制內存使用，一旦內存用盡，exception寫寫好，處理得漂亮一點就沒事了。像xen那樣跑車變成黃魚車？這個提都別跟我提。
二、Openvz和Xen的實戰比較
一、規格說明：
OpenVZ： Ramhost 512MB Plan
Xen： Photonvps 512MB Plan
二、Unixbench分數
很多人可能不知道這個東東，事實上這是國外測試VPS性能非常流行的一個軟件。
雖然看上去山寨了點，但是是好東西。事實上，以性能爲賣點的vps hosting公司大部分都會給出unixbench-wht-2的成績來以示其牛叉。
例如：clustered，silverrack，等等。
這個分數的意義是你的性能與一臺標準P233MMX （FreeBSD 2.x， 128MB RAM， SCSI 7200RPM）的性能比，越大越好。
他的一些測試項目如下
| dhry2reg 內存的register性能 whetstone-double 雙精度浮點性能 execl execl call性能 fstime 文件系統性能 fsbuffer 文件系統性能 fsdisk 文件系統性能 pipe 管道(pipe)的性能 context1 管道上下文切換的性能 spawn 創建進程的性能 shell shell併發性能 syscall 系統調用性能 |
如果這樣不直觀的話，我來說一下我用過的一些VPS/shared host的unixbench成績吧。
| mediatemple dv($50的那個) 30- hostmonster basic 60+ rapidxen 最低配 60+ 我的IBM [email protected] 110+ stdyun.com ~300 |
好的，那麼進入正題，我所用的兩家公司的openvz和xen的性能比較
| Ramhost.us OpenVZ ----------------------- INDEX VALUES TEST BASELINE RESULT INDEX Dhrystone 2 using register variables 376783.7 9652226.8 256.2 Double-Precision Whetstone 83.1 1335.8 160.7 Execl Throughput 188.3 5379.2 285.7 File Copy 1024 bufsize 2000 maxblocks 2672.0 154554.0 578.4 File Copy 256 bufsize 500 maxblocks 1077.0 44083.0 409.3 File Read 4096 bufsize 8000 maxblocks 15382.0 818801.0 532.3 Pipe-based Context Switching 15448.6 260826.7 168.8 Pipe Throughput 111814.6 1144518.6 102.4 Process Creation 569.3 15241.2 267.7 Shell Scripts (8 concurrent) 44.8 989.8 220.9 System Call Overhead 114433.5 1206388.1 105.4 ========= FINAL SCORE 241.1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PhotonVPS Xen ----------------- INDEX VALUES TEST BASELINE RESULT INDEX Dhrystone 2 using register variables 376783.7 33564046.7 890.8 Double-Precision Whetstone 83.1 1418.2 170.7 Execl Throughput 188.3 5122.2 272.0 File Copy 1024 bufsize 2000 maxblocks 2672.0 145582.0 544.8 File Copy 256 bufsize 500 maxblocks 1077.0 40877.0 379.5 File Read 4096 bufsize 8000 maxblocks 15382.0 1367761.0 889.2 Pipe-based Context Switching 15448.6 448013.6 290.0 Pipe Throughput 111814.6 1703063.9 152.3 Process Creation 569.3 15826.5 278.0 Shell Scripts (8 concurrent) 44.8 1551.2 346.2 System Call Overhead 114433.5 2237909.1 195.6 ========= FINAL SCORE 336.8 |
其中PhotonVPS因爲使用了8核，所以是用。/Run 8來測試的分數。
通過比較可以發現，兩者的浮點磁盤性能什麼的都差不多，差異巨大的在於register性能，因爲8核寄存器比較多的關係吧大概，所以分數巨高無比。所以整體上PhotonVPS要比ramhost高出一大頭。需要注意的是，並非所有的openvz主機和xen主機的性能都是如此，事實上，取決於不同服務商的配置和你所在節點的負載，性能會差異很大。例如mediatemple的類openvz系統分數就只有30，而rapidxen的xen系統分數就只有60，等等。
三、實際項目的性能比較
以SimpleCD爲例，分別架設到ramhost和photonvps上。
SimpleCD項目簡介：可以看作一個1G sqlite3數據庫用python進行查詢的項目，當然因爲我程序寫得不好，剛學着用數據庫，數據庫設計上有問題，再加上用的是比較悲劇的sqlite3，不太適合太大的數據庫，所以性能很低。不過也好，正好用來測試VPS的性能，看openvz和xen在悲劇的數據系統下表現如何。
ramhost上數據庫可以正常查詢，第一次查詢時間比較長，後來基本上都在1秒內。
photnxen上數據庫不一定可以正常查詢，經常出現超時現象。
這個事實非常奇怪，好奇之下我登錄了sqlite3，測試單條指令的執行時間，事實上證明還是photonxen比較快。但是爲什麼網站方面會差那麼多呢？原因我覺得是xen的內存問題。
補充，後來我換了mysql數據庫，mysql比sqlite更爛，所以結論就很明顯了，瓶頸就在內存上面。就如我之前推測的，xen的內存使用太大，很多隱性消耗下，web.py運行時佔用了大量內存，導致作sqlite3查詢時需要不停地swap，這樣一來自然就要超時了。
本來還想用ab來測試併發性能的，但是這麼一來就有點太欺負xen了，所以這個測試就不做了。
四、好好利用寄存器性能
這個算是題外話，因爲不是所有的xen都像photnxen那麼強大的。
爲什麼想到這個？是因爲我用lzma壓縮數據庫時，photonxen要比ramhost快一點。
想想就知道原因了，這種壓縮算法非常耗CPU，這時候寄存器性能就派上大用處了。
那麼同理可以推測，它處理視頻轉換什麼的那也應該是相當的拿手。
現在PSP/手機用的挺多，但是很多視頻無法在手機上看，得轉換以後再看。用自己的電腦轉換太慢了，現在好了，只要用離線下載的方法下載資源到服務器，然後服務器自動運行腳本轉換爲MP4，然後自己再直接去服務器上拖，一舉n得：
1.轉換p2p下載爲ftp下載
2.節省視頻轉換的時間
3.因爲MP4一般比較小，還節約了從服務器下載到本地的時間
五、結論
1.在同樣的情況下，xen的內存消耗大於openvz，尤其當處理大文件時
2.內存用盡的情況下，xen的性能極度下降
3.一般的使用條件下，xen的性能不弱於openvz（lzma，ffmpeg等）
4.總得來說openvz性價比更高一些，因爲它允許你在和xen相同的內存限制下運行更多的程序，而且不影響性能，前提是你要會管理內存，否則openvz會是一場災難。
所以
誰適合使用xen？
1.沒有大文件需要處理
2.內存要求不高的應用（或者說很低的應用）
3.對響應時間要求不高的應用（因爲內存用盡時響應會非常慢，真的，你試過vi一個文件要等上1分鐘麼？）
4.看重穩定性多過性能的用戶（即使內存用盡，響應很慢，還是會響應）
誰適合使用openvz？
1.對內存極度渴求的應用
2.善於進行內存管理的用戶（沒內存時直接仆街，沒有商量餘地）
3.追求性價比的用戶（前提是openvz的服務商不是黑心服務商，沒有像mediatemple那樣做出苛刻的限制，並且最低前提下不oversale它的VPS）
4.更瞭解linux的用戶（openvz因爲不夠底層，所以很多東西是用不了的，比如pptpd，這就要求用戶換用其他更爲難用盡管可能也更爲強大的軟件，比如openvpn）
三、廉價高性價比VPS推薦
自覺交學費交了不少，有點經驗了，不敢藏私，分享一點自己的心得吧。
以下主機是我推薦的：
其中寫了推薦的幾個我詳細研究過他們的plan，雖然沒用過，但是覺得都還不錯。