如何決定主機是否要分流?

disp.cc 是個很有特色的電子布告欄網站,它用http + Ajax做出類似BBS的瀏覽效果,而且比BBS更好用。作者是台大電信所畢業的高材生。最近,disp.cc的人氣愈來愈高,我也順便看了一下,disp.cc的站長,knuckles是如何處理分流問題的。

引述站長在他個人的文章中,寫下的效能調校方法:

disp.cc load balancing structure

不過弄了之後發現,在一樣的價錢下,一台16G + 一台8G 的效能,比一台 24G 的效能好太多了 之前用單獨一台24G時,記憶體還空著很多,系統負載就飆高了… 看來要增加使用者不是單純加記憶體就好了

disp.cc的站長是租用日本的主機,所以有RTT上的優勢。而且該日本的主機商有提供一些高級的分流工具,例如node balancer,所以站長也可以相對容易完成分流這件事。雖然我個人認為,disp.cc站長做的決策非常的正確,但是,我卻不會建議我所有的客戶採用類似的解法。要說明這個觀點,要先從disp.cc的web server 設定開始講起。

Disp.cc的web server架構

在我寫這篇文章的時間點,disp.cc使用的web server是apache 2.2.15,PHP/5.4.20。雖然說,我沒有進一步的效能調節資訊,但是從站長提供的資料,我會猜測,之所以會發生『單獨一台24G時,記憶體還空著很多,系統負載就飆高了這種情況,這跟apache C10K問題有關。

apache C10K問題

這個問題是這樣子產生的:對於要寫網路程式,最直覺的寫法,就是用阻塞式I/O並且配合多執行緒。( blocking I/O & multi-thread ),又稱之為thread-model的寫法。這樣子雖然是最簡單最直接的寫法,在連接數(connection number)到達一萬(10k)時,因為大量的執行緒不停地做環境切換(context switch),導致增加硬體也無法提升效能的窘境。Context switch帶來的效能損耗會隨著執行緒(thread)愈多愈加嚴重,終於在10000個連接數時,到達崩潰的時間點。以今日的瀏覽器,往往輕易地可以產生6~10個平行的連接數,同時上線人數到達2000人時,這個C10K現象就會日益嚴重。

C10K問題的解法

相對於傳統的阻塞式I/O和多執行緒寫法,另一種寫程式的寫法,是使用非阻塞式的I/O,單一執行緒處理大量連接的寫法。代表作品是nginx。( nginx為了可以發揮多核心處理器的效能,也是可以生成多執行緒的,但是本質上,nignx還是使用event-model來處理連接數的問題。) 我的客戶中,有同時1萬人上線的大論壇,用了nginx之後,就可以用獨立主機(dedicated server)順順地跑。

disp.cc這個站,雖然沒有使用event-model來處理,但是因為分流的緣故,每一台機器上的connection數剩下一半,如此一來,就巧妙地迴避了C10K問題。除此之外,一般而言,VPS的架構,不同的VPS,硬碟的IOPS也是獨立的。所以這種分流也迴避了硬碟I/O的瓶頸。

VPS 與 Dedicated Server

從價格上來說,一定是VPS便宜。但是真的要講性價比的時候,獨立主機(dedicated server)因為可以使用百分之百的硬體資源,反而可以有更高的性價比。也就是說,同樣一塊錢買到的硬體運算效能,Dedicated Server一般而言是大於VPS。

獨立主機雖然性價比高,但是如果遇到了這種C10K問題,沒有使用event-model來處理,就變成一定要分流。而且這種時候的分流是不經濟的,因為如果主機上的資源尚未充分使用就分流,這就造成了資源上的浪費。除此之外,VPS比較具有彈性,如果5000個connection只要使用2G的RAM,我們可以輕易找到提供2G RAM的VPS。但是獨立主機的硬碟規格就不能如此隨意地客製化,獨立主機配合不同世代的CPU,RAM的大小會愈來愈大。

總結,如果某個大站的站長想要節省主機的費用,一般而言,使用獨立主機,可以比VPS省到30%~50%左右。但是,使用獨立主機時,就可能不適合參考disp.cc現行的分流方式了。