作者kojilin (呵呵呵噗噗噗..搞笑..)
看板Ruby
標題Re: Ruby on Rails 的速度議題
時間Sat Oct 21 10:24:44 2006
※ 引述《b6s (http://b6s.blogspot.com)》之銘言：
: 唔，沒有數據確實是很麻煩的事。
: 純粹就常理推論的話，只要套 Amdahl's law 就可以了。
: 我印象中也只有 Beyond Java 一書及其相關討論稍微提到，
: 因為 ActiveRecord 實作出來的 OR mapping 比 hibernate/spring 之類的機制快，
: 另外又省掉了很多讀寫 xml 檔的 I/O，
: 於是 RoR 現階段比某些 J2EE solution 快。
: 另一方面，動態頁面生成的那一段，恐怕是使用者最有感覺的部分；
: 而這部分，嗯，J2EE solution 一直都只能算是可接受的速度而已。
: 各家 servlet engine 可能要負點責任。
我來平反一下J2EE的東西..hehe..
首先AR跟Hibernate比
為何AR被提到過比較快(這邊我也沒測過效能所以用別人提到的)
我想有可能的部分在於AR提供我們了平常會遇到的狀況,
而Hibernate這類卻是一開始就針對"完整"的狀況
當然我對兩者的目標都喜歡,畢竟平常的web app開發,
通常不會遇到那種很特別的問題
只是看看文章,頗多都有點舊了,AR跟Hibernate也都有更新了
而且也沒有詳細的數據比較
就算有也頗難測的,畢竟立場點就不同.只要同樣等級的機器上比較就公平否?
都寫在console下測試?之類
另外hibernate+spring,是為了DI跟抽象化和改良,
如果要比應該是要看純AR跟Hibernate
還有xml 檔的 I/O,這個大部分是一開始啟動就做完的東西
所以根本沒這種狀況,尤其在production mode下通常也不會希望是一直監控
xml檔案一有改變就重新deploy.
所以就算有效能瓶頸,這部分不太會是重點.
讓小弟提供個數據:)
動態產生頁面的部分,像我自己管的
透過google analytics,平日一天七萬page,人數大概快萬.
而同台機器上除了跑forum之外還有另外兩個service
當然另外兩個流量不大所以只統計了forum部分
這樣forum的平均處理時間也只有40~100ms
(這邊我沒問開發者對cache做到何種程度,但是我想至少有tune過的效能也是不差的)
這台server還是跑J2SE1.4.2(如果有關心Java的,可以看看5.0跟6和1.4.2的效能差異),
主機是兩年前的光華牌吧
AMD 2500+ 跟 1G ram..所以說效能會差嗎?我並不覺得
至少他不是 "只能算是可接受的速度而已"
當然如果你說的是有關EJB相關的,我想那就跟Rails的目標很遠了
也應該不是比較對象了:)
koji
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.167.165.115
1F：推 qrtt1:唔,這裡的EJB是指3.0之前嗎? 好奇地問 10/21 10:54
2F：→ kojilin:不管是不是3.0囉,3.0之後是有變好寫,但是效能上 10/21 11:01
3F：→ kojilin:畢竟是在EE Application Server上跑,提供的服務一多 10/21 11:03
4F：→ kojilin:效能上就一定會拖累到~ 10/21 11:03
5F：推 qrtt1:嗯, 同感。剛剛突然想起了jdo google了一下，已經看到被稍為 10/21 11:23
6F：→ qrtt1:dead-end 了.... 真可憐啊>"< 10/21 11:24
7F：推 PsMonkey:啥？ JDO 掰掰了？這這這... 好棒阿...(還好當初沒買書) 10/21 11:33
8F：→ qrtt1:只是有人覺得@@ 是不是8181 天曉得 10/21 13:10
9F：→ kojilin:沒掰吧..bea的kodo也在..只是沒有另外兩家有聲勢罷了~ 10/21 16:31