disp.cc 是個很有特色的電子布告欄網站，它用http + Ajax做出類似BBS的瀏覽效果，而且比BBS更好用。作者是台大電信所畢業的高材生。最近，disp.cc的人氣愈來愈高，我也順便看了一下，disp.cc的站長，knuckles是如何處理分流問題的。
引述站長在他個人的文章中，寫下的效能調校方法：
不過弄了之後發現，在一樣的價錢下，一台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現行的分流方式了。