之前比較PHP和ASP.NET的時候，提到了Share-Nothing-Architecture，這是PHP創始人Rasmus Lerdorf提出的概念。PHP采用的就是Share Nothing Architecture，各個HTTP請求之間在PHP這個層次是不共享任何狀態的，這樣的好處是可以使得PHP應用程序具有很高的擴容性(Scalability)。

　　世上的事情就是有利就有弊，SNA(Share Nothing Architecture)也不是沒有缺點。采用SNA來構建傳統的Web 1.0或者大部分Web 2.0應用都沒問題，但是用來構建Comet應用就成了問題。

什么是Comet?

　　用例子來說明最容易，試著同時登陸兩個GMail賬戶，從一個賬戶往另外一個賬戶發一封信，可以看到，這邊剛剛按Send按鈕，那邊就提示收到新信件了。這種用戶體驗就是好像這封信是從Server被Push到瀏覽器一樣，但是我們都知道HTTP協議是不支持Push的，只能是Client發一個請求，Server返回一個響應，Client再發一個請求，Server再返回一個響應，那GMail是怎么做到的呢？這就是在HTTP協議基礎上的Comet技術。

　　簡單說來，Comet就是讓瀏覽器Client端保持一個到Server的長時間的HTTP請求，瀏覽器發出這個HTTP請求之后并不指望Server立刻返回點什么，Server愿意什么時候返回就什么時候返回，而且即使返回了寫什么也不著急斷開這個鏈接，Server可以通過這個連接返回一些東西到瀏覽器。總保持一個Client和Server端的HTTP隨時待命，這樣，Push就實現了。

為什么PHP不適合Comet?

　　準確來說，并不是PHP不適合Comet，而是PHP的容器不適合Comet。通常PHP都是和Apache配合使用，Apache是世界上使用最多的Web Server，但是它的設計不適合新興的Comet應用。

對每個HTTP請求，Apache會分配一個線程或者進程來處理，問題是，被分配的線程或進程不處理完這個HTTP請求是不會去做別的事情的，也就是說，這個線程/進程被這個HTTP請求占用了，這也是Share Nothing Architecture的應用。

　　為了實現Comet，每個瀏覽器都要建立一個和Server的“長時間的”HTTP信道，對于Apache而言，就是對每個瀏覽器訪問都要有一個線程或者進程伺候著。可以想象，隨著用戶數的增加，需要的進程和線程數也線性增加，而且大部分時間這些線程和進程并不做實際工作的，這很影響Scalability。

　　如果Apache被修改成異步方式，那么PHP作為一門語言還是可以實現Comet的，但是我想Apache永遠不會這么改。而且，PHP也不是被設計成來處理異步請求的，現在有很多其他語言、平臺和服務器支持異步了，如果真的需要實現Comet，就不應該選擇Apache + PHP。