這是直譯式語言的悲哀

不過,我想,大部份人都不會知道慢在哪 XDD

我在8樓也說沒啥意義了
不過看別人這樣high .... 不好意思潑冷水

multi-thread的複雜度 還是分很多種
要看使用的方式跟規劃

Dear anderson1127,

> 其實我會建議樓主不要在LAMP的架構下來做Multi-thread 的程式 , 沒有意義!!
> 最重要的理由是 Apache + PHP本身的架構就不是Multi-thread !!

除非搭配 Apache Worker 模式，才有可能作到 Multi-thread。

我後來查閱 Multi-thread，很遺憾，Ruby 也要 jRuby 才有真正落實 Multi-thread，這部份的討論還蠻多的。

所以，我後來認為 LAMP 本身還是以快速開發雛型比較適合，需要大型架構，還是比較建議以 Scale-out 的方式分散運算，程式語言有本身的限制與原始設計要滿足的需求，There is no silver bullet.

這部份可以參考 Accelerate your LAMP

> Apache本身在執行PHP script時, 就必需要進行Fork Process ,每接一個Client Connection
> 就必需要Fork一個Process 來處理這個Connection , 不管你用什麼PHP Framework
> 都沒有例外 !!

就算改用 FastCGI，也是同樣受限 session，一樣無解﹍

> 因此,在LAMP架構之下,沒有辦法做到以Multi-thread base的PHP Application ....

是的！

> 最多只能夠針對PHP script的compile time來進行改善, 不要每執行一個php script
> 都去compile 一次php script (FastCGI記得就是處理這方面的事)

是 APC 或 OP-Cache 這類 PHP Accelerator，我在Optimize TurnKey Linux for ZurmoCRM 有提到這種加速方式。

> Web Application設計時就必需要注意,盡量不要有跳不出來的回圈,程式設計師應該要特別注意
> 如果有這種潛在問題,就會造成Memory的消耗!! 有再多的Memory ,也不夠花 ...

這個我持保留態度，原因是 Session Pool 本身就會有個 service 一直常駐，除非被 Kill，而他雖然消耗 memory，但節省不少與 DB 建立 connection 的時間。或許限制記憶體上限，並設定 garbage collection 時間，會有幫助在 memory consumption 與 效能上取得平衡。

> Multi-thread programming 的精神所在就是降低Memory 的消耗 ,如果架構設計得夠好
> 甚至可以有效利用Multi-Core CPU , 達到加速運算目的!!

這個我持保留態度，因為我認為 Multi-thread programming 是要能善用處理器計算資源，但不一定降低消耗 memory consumption

> 只是很可惜的, 在PHP世界裡,我還沒看到有人發展For PHP Multi-thread Framework

語言本身不行，Ruby 有假 multi-thread，只要不是搭配 jRuby

> 要寫Multi-thread programming 要有一個覺悟,它的複雜度 , 比得上自己寫一個OS
> 這不是一般會寫PHP程式的人想像得到的事...

確實如此，這也正是高級程式設計師的價值所在之一！

感謝您特地分享寶貴經驗！

Have a nice day!

Best regards,

Amigo

Dear vampire,

> multi-thread的複雜度 還是分很多種
> 要看使用的方式跟規劃

是的，非常同意，Multi-thread 與平行處理一直都是比較進階的程式設計主題之一。

Have a nice day!

Best regards,

Amigo