unityoxb 发表于 2012-08-23 13:57 static/image/common/back.gif
回复 13# fiendcly
新版本的zf早已经是懒加载模式了，只在需要的时候才include。
............
其實真正的原因是.....就是 ZF 在 INIT 時.
會自動動態 加載一大堆檔案
導致 伺服器 IO 變的很重 而無法應付 高流量的服務.
有空你可以 ab 自己 用 PHP 純寫一個 程式~
和 INIT 一支 ZF 來看看..
fiendcly 发表于 2012-08-23 21:48 static/image/common/back.gif
...........
其實真正的原因是.....就是 ZF 在 INIT 時.
會自動動態 加載一大堆檔案
導致 伺服器 IO 變的很重 而無法應付 高流量的服務.
是的，所以ZF是重型框架。但并不能因此说它无法应付高流量访问，更准确地应该说是在小规模低成本应用环境里，它的运行效率较低，如果作为企业级应用来说的话，结合服务器集群部署、负载均衡、缓存配置等综合环境再看，效率反而会更理想，就如同我们要运送一些小宗商品会选择汽车，但货物量庞大的话，就该选择火车轮船了，所以这些IO成本开销是有其理由的……
我做过一些简单的ab测试，ZF并不比TP和Yii差多少，当然不能和原生代码比。没必要在原生php和框架之间比较纠结，就是汽车和火车、轮船的区别，我们都会坐的。
个人认为网站开发语言在进化，原生PHP会逐步沉到底层变得相对“低级”。另外，在云计算平台上，可能IO、并发、带宽这些牵扯web开发人员神经的词，很快就不会再被注意了，就像我现在买电脑，再不会像以前那样追求什么时候CPU速度和内存、硬盘大小了，什么i7、i5，都是浮云。
本帖最后由 fiendcly 于 2012-08-24 20:11 编辑
unityoxb 发表于 2012-08-24 10:45 static/image/common/back.gif
是的，所以ZF是重型框架。但并不能因此说它无法应付高流量访问，更准确地应该说是在小规模低成本应用环 ...
我不是有意要跟你 對這件事辨論....
不過我不完全讚成你的說法喔.
ZF INI 一口氣會 拉幾十個個物件庫進來.
也就是說 10 個人進來 還不算 PROCESS 就直接會吃掉 一堆 IO 了.
也因為這樣我們有一個服務 , 因為之前的人大量用了 ZF, 所以我們多採購了 三百台伺服器.
來應付 IO 的問題.
那個服務有五千萬人.做 SNS 服務 .
CACHE , BUFFER , OPTIMIZE 能做的都做了 .
I/O 的問題還是無法改善.
如果你真的有用 AB 測試.
你可以寫一支PHP 讓它 INCLUE 10 支 OBJ 檔 和 把 10支 OBJ 檔 放在同一支程式跑看看.
AB 的速度會直接 每 INCLUDE 一個掉 100~200 個 請求數 , 看 SERVER 的效能.
而 ZF 大量動態載入 的方式 , 會造成 IO 非常吃緊.
如果當初不是用 ZF 那個服務應該 只要 30 台就可以搞定了.
不是沒做 CACHE 和 BUFFER ..... 而是 要初始化它就要吃掉一堆IO ....
####
270 台伺服器 , 相當要台幣二千七百萬 , 也就是 5百多萬人民幣.
如果用在雲端伺服器的話 , 以 CPU 硬碟 流量計價....
會是很可怕的天價...
現階段的 雲端伺服器還有很長遠的路要走 , 因為價位不會比自己做 IDC 便宜.
######################################################################
所以 :
我是想告訴大家 ZF 不適合做為高流量 網站的開發工具.
大家在使用上要小心.
沒有人流又趕時間的拿來用就好.
如果有公司的新進同事問我~ZF 是什麼 我每次都會回答~是玩具~玩玩就好.
因為我們公司的服務情形不適合 用 ZF.
fiendcly 发表于 2012-08-24 19:35 static/image/common/back.gif
我不是有意要跟你 對這件事辨論....
千万级用户的SNS，瓶颈应该在数据库方面了吧？相比起来ZF初始化的那些IO不算什么吧？你说的ab测试，原生代码不include那有意义吗？难道你们的原生代码不include？很奇怪。如果不是数据库而是程序方面的原因，代码编写存在的问题可能性更大。ZF的额外开销肯定是有，但不至于像你说的这么夸张要多加270台服器，如果真是这样，为什么不用那二千多万台币找人弃用ZF代码重构程序，比部署270台服务器更麻烦吗？怀疑你们的技术实力哦。
请不要误导“新进同事”说ZF是玩具，像当初那些Java程序员说PHP是玩具一样，有点不负责任哦。
本帖最后由 fiendcly 于 2012-08-25 13:13 编辑
unityoxb 发表于 2012-08-25 10:15 static/image/common/back.gif
千万级用户的SNS，瓶颈应该在数据库方面了吧？相比起来ZF初始化的那些IO不算什么吧？你说的ab测试，原生 ...
怀疑你们的技术实力哦。
请不要误导“新进同事”说ZF是玩具，像当初那些Java程序员说PHP是玩具一样，有点不负责任哦。
先跟你道歉我不應該說`ZF 是玩具.
上述的情況是因為我們的服務流量很高...所以我才跟新進同人這麼說.
開口就攻擊別人....不是很好....這件事做實驗就可以知道結果了 .
我們有一百多個人 別一口氣全罵 , 還是有很多比我利害的人..
那專案不是我寫的 , 我是比較上層的主管......
那項目組當時發生這件事差點被我裁掉了 , 我也覺得那組人技術實力有問題. >_<"
如果你對 ZF 的 IO 的支持度那麼高 , 做個實驗就好了.
基本上我對用什麼語言和工具沒什麼偏見 , 只要適合就好了.
對 ZF 也沒特別的偏見 , 只是對它在~IO 上的效能不是很同意它能用在高流量的系統.
##################
另外 我們沒用 DB 全都使用快取和轉 MEMCACHE BUFFER 了.
多層和分散式架構 用 MC 等降低~DB 效能 .... 不是新技術也不是新聞...
300台機器本來要買 , 先解決問題..等新版抽掉 ZF 的版本出來可以拿來用在別的地方.
所以後來我下令 公告 公司 所有程序員一律禁用 ZF 寫 SNS 服務.
把很多元件都轉成用 C++ 開發.
########
也不是什麼專案都會服務千萬人數的用戶~ 我倒不是很排斥用 ZF .
ZF 的 IO 就是真的很重.....
如果用純 PHP 開發 跟 用 ZF 開發 效能差了 十倍以上.
而且這件事也沒什麼好爭的.
如果你不相信~可以做實驗 , 實驗證明一切~~~
本帖最后由 fiendcly 于 2012-08-25 13:24 编辑
http://leftblank.nl/php-framework-benchmark-zend-codeigniter-cakephp-481.html
這裡有篇 Benchmark 的比較表.
Requests per second (5 run avg)
Baseline PHP 2237,05
Cake 1.2.1 101,03
Cake 1.2.3 103,68
CodeIgniter 1.6.2 221,86
CodeIgniter 1.7.1 229,50
Zend 1.7.5 126,90
Zend 1.8.1 128,85
這是效能差異~~~
Baseline PHP 2237,05
Zend 1.7.5 126,90
Zend 1.8.1 128,85我實驗的結果也差不多.
差了快十幾倍.
後來 查到 IO 時發現 ZF 本身邏輯運算沒什麼問題.
主要是 INIT OBJECT 時 IO 佔掉太多伺服器的資源了.
我很期待 ZEND FRAMEWORK 可以全部編譯成 zend_framework.so 讓 PHP DL 可以 直接用.
這樣就沒這問題了它將會是很好的工具.
參考看看.
fiendcly 发表于 2012-08-25 12:24 static/image/common/back.gif
先跟你道歉我不應該說`ZF 是玩具.
上述的情況是因為我們的服務流量很高...所以我才跟新進同 ...
跟我道歉不必的。申明我不是ZF的fans，虽然写了这本书……所以不刻意维护它，只是客观讨论，不带啥情绪。我现在开发项目也是根据情况，有时候用Yii，有时候也用纯PHP，汽车、火车、飞机都会坐，看情况了。
本帖最后由 fiendcly 于 2012-08-26 06:43 编辑
unityoxb 发表于 2012-08-25 14:36 static/image/common/back.gif
跟我道歉不必的。申明我不是ZF的fans，虽然写了这本书……所以不刻意维护它，只是客观讨论，不带啥情绪 ...
不管怎麼樣 , 寫書出來教育大家是個偉大的工作.
在台灣寫書的利潤低 , 懂又願意寫的人不多.
所以 這幾年來我己經沒興趣再買台灣人寫的 PHP 用書了.
通常都是小小工作室 很不用心的抄一堆國外的文章和翻譯 , 質量都很差.
也因為這樣多半台灣的程序員都買原文書......
呵呵 , 所以我是真的很誠心的感謝 作者 您 在 技術推廣上的 貢獻 的.
如果 下次再到北京出差 , 小弟會到書店拜讀您的書籍 , 並且買一本回來收集.
它幫很多初學者解決很多疑慮 並且帶給大家好的觀念.
針對 ZF 的 IO 問題大家可以參考看看 上面的討論.
分享一下我對原生框架的設計心得 :
現在技術真的日新月異.....十四年前 , 小弟初次使用 PHP 時 , 當時主流還是 C 和 PERL .
我第一本PHP的書是 WROX Professional PHP , 翻了這本書後我開始迷上 PHP
Professional PHP
後來又買了本
Professional PHP4
之後又出了本
Professional PHP5
其中 PHP4 那本寫的最好.
PPH4 這一本 找來了 十一個 PHP 高手一起寫這本書 , 每個人負責自己的單元.
我最欣賞的 就是 "多層式架構開發" 這個單元.
九年前我因為這本書的觀念 , 採用了大量的 PHP+XML+XSL 的 框架應用 ,
研發了 LIBXML+LIBXSL 的 七層式的架構框架.
利用它 架設了非常多百萬級流量的WEB服務.
在管理 , 維護 , 和開發上 至少提昇了 團隊十倍以上的速度和品質.
可惜這幾年 JSON 當道 , 不管是導入或是教育 都是習慣用 JSON , 因為它的入門門橍較低 人也是會懶散的 , 總挑簡單方便的方式做.
所以我用 PHP+XML+XSL 用了五年後被迫改用 JSON.
但是因為當時有這樣的 經驗 , 我在 PHP 的多層架構開發上 視野 大了很多.
當時真旳很多學 JAVA 的人說~PHP是玩具 , 在我眼中 ,PHP是一套強大的 C/C++ 整合的 SCRIPT.
比起 JAVA 和 PHP 在效能上 和 整合上 是爆龍級的工具程式.
我最看不起 JAVA 的是 JVM 在 時間上 只能處理到 千分之一秒的狀況.
所以 處理 網路層的程式 , 我從來不用 JAVA 都採用 C/C++ .
早期~PHP4 在 在記憶體管理上 問題很多 , 到了 2006年底 PHP5.2 出來後才有了重大的突破.
多了 memory-limit 和 memory trace 的工具函式.
可惜它還不是能夠很穩定的做為一個 長時間運作 PROCESS 的語言.
也因此 + OOP 普及化 它硬生生的被 JAVA 給 擠掉了.
真的很可惜 PHP 好的觀念和書籍不多
加上~JAVA 被 SUM 用力的推廣教育 , 所以 PHP 才輪為 JAVA 程序員口中的 "玩具"
我覺得 它是這十幾年來我看過最有價值~PHP 書籍~~
可惜 除了 Professional PHP5 , 其它二本 都己經 停止發行了.
WROX 中間有被併購~~這幾年的質量也沒以前好.
"多層式架構開發" 的觀念會讓你完全跳脫~MVC 的架構 ,
你將會把 PHP 的原生框架寫的更靈活更方便維護.
熟悉 多層式架構開發後 你將會發現 MVC 的觀念 應用在 WEB 上其實是有很多 開發 / 維護 / 整合 的問題的.
你不會再把 Presentation layer 放在 content logic , 不會把 content logic 放在 Presentation layer .
在MVC的 V和C中間 又加開了二層的觀念 , 更嚴謹和標準化的架構你的框架.
讓你的程式的 可重覆利用性和維護性提高數十倍. 開發速度也會提昇非常的多.
讓你的 CODE 更簡潔 而且可以大量的重覆利用.
這是使用 現成的框架不能教你的.
這幾年 寫程式的工具愈來愈多 , 這類較偏框架設計的書反而變少了.
分享 給 有能力或興趣自己寫框架的人參考 .
助大家順心.
fiendcly 发表于 2012-08-26 05:27 static/image/common/back.gif
不管怎麼樣 , 寫書出來教育大家是個偉大的工作.
在台灣寫書的利潤低 , 懂又願意寫的人不多.
很谢谢你。读你的帖子让我受益良多，有机会请多指教。我只是想把开发中的一些经验拿来和大家分享，并借此和同行们增进交流，促进自己的学习，与博大精深的php知识相比，这书涉及只是一些粗浅的皮毛，“教育”大家远远谈不到，见笑方家了。
unityoxb 发表于 2012-08-27 16:10 static/image/common/back.gif
很谢谢你。读你的帖子让我受益良多，有机会请多指教。我只是想把开发中的一些经验拿来和大家分享，并借 ...
就是您花時間 , 才讓更多人可以快速入門 PHP , 別 謙虛 是您應得的讚許.
另外我把 多層式架構的開發框架設計 寫了一些教學 有空可以參考 -
http://bbs.chinaunix.net/thread-3767412-1-1.html