Ruby on Rails 的速度議題

[giive (lala)]

出自我的Blog
http://lightyror.blogspot.com/2006/10/ruby-on-rails.html

剛剛看了 JavaEye 裡面的 從JavaEye2.0網站看ruby on rails性能討論串，裡面 Robbin 有提到

    單純比較JVM，PHP解析器，ruby解析器的話，肯定是JVM最快，ruby解析器最慢，這?結論是很明确的事情了。

    但是對于一?具体環境部署的web應用?說，這?web應用体現出?的吞吐量，負載能力，是取決于很多因素的，解析器的性能只是其中一?因素而已。而且通過一系列實踐?看，ruby解析器的低性能對于整体web應用性能的影響并不明顯。

    因此ruby解析器雖然性能差，但是ruby on rails開?的web應用性能卻并沒有表現得差，甚至還挺不錯的，這?就是我想說明的。

    至于非要和PHP和Java比較，其實意義不大，因為影響web應用因素很多的，往往最終性能的瓶頸都是數据庫。

想起大家一直挑戰（討戰？）的效率問題，讓我激起了解說的慾望，非得好好解釋這一篇不可。如果按照右邊的圖，一次 Ruby on Rails Web Query 時間可能會消耗在四個地方

   1. 網路傳遞時間
   2. Web Server 處理時間
   3. Ruby on Rails 處理的時間
   4. DB 處理的時間

大致上就是這四個地方。

網路傳遞時間一般來說，跟用戶端的頻寬大小有關(就是你 ADSL 的速度快不快），一般來說網路傳遞時間慢通常是用戶端這。如果討論伺服器端，網頁傳送的 HTML 檔案大小，以及伺服器租用的頻寬也有關係。通常大家的網頁大小都大同小異，伺服器機房的頻寬也是靠錢就可以解決的。要從伺服器端解決網路傳遞時間，可以在傳送檔案時壓縮相關檔案（Apache 跟 Lighttpd 有相關 Module ）。


Web Server 處理時間代表 Web Server 接收 request，根據 request invoke 相關的 File 或是 Application Server，得到回應後送回去。這裡差別一般來說不大，不過 Lighttpd 在這方面的效率是有目共睹的。（處理靜態檔案特強）

Ruby on Rails 處理時間就是大家一直質疑的地方，他接收到 request ，作相關的處理，然後回應的時間。這裡的速度取決於 Ruby 的速度，當然眾所皆知，Ruby 已經很慢了，還得加上 Rails Framework 的負擔，當然快不到那裡去。但是，有慢到不能接受嗎？....下面會分析。

DB 處理時間就是 Database 處理 SQL ，查詢資料，回應的時間。這裡的處理時間當資料庫大到一個量時，會呈現大幅度的增加。

再來就是考慮時間比例的遊戲了，我手邊並沒有已經上線，擁有一定流量的 Ruby on Rails 網站，也沒有塞了幾萬筆的資料庫，無法做出很精確的數據計算，大家看看就好，了解我論點的點即可。

我手邊的 Ruby on Rails 隨便一個頁面，HTML檔案，圖片加上 CSS ，大概拉哩拉紮 100K ~ 500K 都很正常，以一般 ADSL 全速來說 250K/s ，大概是 1 ~ 2 sec 可以處理完 。Web Server 處理時間除非是大量的 request ，否則我都當他是不需要處理時間。根據 log 顯示，Ruby on Rails 處理通常在 0.03 ~ 0.05 秒 之內完成。DB query 的時間，因為我現在的 Database 只有短短的數百筆（還沒開發完成呀），所以只能說 Database 時間目前是趨近於 0.005 秒左右的處理時間。

以目前這個正在開發中的頁面來說

   1. 網路傳遞時間 96%
   2. Web Server 處理時間 0%
   3. Ruby on Rails 處理的時間 3%
   4. DB 處理的時間 1%

我們可以發現就算是 Database 時間取的相當小， Ruby on Rails 佔總共回應時間的比例也相當少。使用其他更快的語言，3%變成 1%又如何 ，對於整體時間的加速也相當的有限。

依照我的經驗，一般不算影音檔的網站，整體時間的比例大概為

   1. 網路傳遞時間 40%
   2. Web Server 處理時間 15%
   3. Application Server處理的時間 10%
   4. DB 處理的時間 35%


這個比例完全沒有經過統計，純粹是我以前的經驗的感覺。如果網路傳遞時間不考慮，一般來說，當網站越來越大時，第一個遇到的 Bottleneck 通常都是在資料庫，再來就是 Web Server 的處理能力會越來越重要（耗費記憶體會越多），最後才是 Application Server 的問題。也就是說， Ruby on Rails 的速度重不重要，其實也還好。就回應時間的比例來說，Application Server 的速度其實不是能夠影響整體效率的關鍵 。但是開發框架的開發時間長短，才是Application Server 最重要的事情，不然你幹嘛不用 C 寫 CGI 就好？

你可以選擇一個速度可以接受，開發時間可以更上一層樓的框架，或是接受一個速度不錯，開發時間多個 1 ~ 2 倍的框架（ 根據各方報導，開發時間差個 2倍還是低估了，一般Ruby on Rails體驗者通常是說 4 ~ 7 倍）

今晚，你要選那道菜？

--

  lighty RoR 是一個介紹 lighttpd , SQLite , Ruby and Rails 的 Blog
  http://lightyror.blogspot.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.218.90.242

> -------------------------------------------------------------------------- <

作者: PsMonkey (痞子軍團團長) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Wed Oct 18 23:57:47 2006

先說，我壓根沒用過回血戒，也不知道怎麼用 C 寫 CGI
更重要的是，我不是打著捧 Java solution 反 Ruby solution 來回這篇

只是覺得其中幾個議題很怪異

※ 引述《giive (lala)》之銘言：
: 出自我的Blog
: http://lightyror.blogspot.com/2006/10/ruby-on-rails.html
: 剛剛看了 JavaEye 裡面的 從JavaEye2.0網站看ruby on rails性能討論串，裡面 Robbin 有提到
:     單純比較JVM，PHP解析器，ruby解析器的話，肯定是JVM最快，ruby解析器最慢，這?結論是很明确的事情了。
:     但是對于一?具体環境部署的web應用?說，這?web應用体現出?的吞吐量，負載能力，是取決于很多因素的，解析器的性能只是其中一?因素而已。而且通過一系列實踐?看，ruby解析器的低性能對于整体web應用性能的影響并不明顯。
:     因此ruby解析器雖然性能差，但是ruby on rails開?的web應用性能卻并沒有表現得差，甚至還挺不錯的，這?就是我想說明的。
:     至于非要和PHP和Java比較，其實意義不大，因為影響web應用因素很多的，往往最終性能的瓶頸都是數据庫。

  根據上面這段很多問號的文章
  基本上，Ruby 處理比較漫，這是公認的（至少，不是我說得 XDXD）

: 想起大家一直挑戰（討戰？）的效率問題，讓我激起了解說的慾望，非得好好解釋這一篇不可。如果按照右邊的圖，一次 Ruby on Rails Web Query 時間可能會消耗在四個地方
:    1. 網路傳遞時間
:    2. Web Server 處理時間
:    3. Ruby on Rails 處理的時間
:    4. DB 處理的時間
: 大致上就是這四個地方。

  我對 TCP/IP 還有 HTTP 通訊協定也不熟
  （咪的，除了嘴泡，你有啥是熟的？）
  但是，把網路傳輸時間（以 client 的網路速度來計算）
  與 Server 運算時間合併來評估 RoR 的運算效率其實不那麼重要
  略感奇怪...

  （那麼，直接要求 RoR 跑在一台較高速的電腦，
    效率問題不就更不那麼重要？）


以下有部份文章重新斷行，方便引言

: 網路傳遞時間一般來說，跟用戶端的頻寬大小有關(就是你 ADSL 的速度快不快），一般來說網路傳遞時間慢通常是用戶端這。如果討論伺服器端，網頁傳送的 HTML 檔案大小，以及伺服器租用的頻寬也有關係。通常大家的網頁大小都大同小異，伺服器機房的頻寬也是靠錢就可以解決的。要: 從伺服器端解決網路傳遞時間，可以在傳送檔案時壓縮相關檔案（Apache 跟 Lighttpd 有相關 Module ）。
: Web Server 處理時間代表 Web Server 接收 request，根據 request invoke 相關的 File 或是 Application Server，得到回應後送回去。這裡差別一般來說不大，不過 Lighttpd 在這方面的效率是有目共睹的。（處理靜態檔案特強）
: Ruby on Rails 處理時間就是大家一直質疑的地方，他接收到 request ，作相關的處理，然後回應的時間。這裡的速度取決於 Ruby 的速度，當然眾所皆知，Ruby 已經很慢了，還得加上 Rails Framework 的負擔，當然快不到那裡去。但是，有慢到不能接受嗎？....下面會分析。
: DB 處理時間就是 Database 處理 SQL ，查詢資料，回應的時間。這裡的處理時間當資料庫大到一個量時，會呈現大幅度的增加。
: 再來就是考慮時間比例的遊戲了，我手邊並沒有已經上線，擁有一定流量的 Ruby on Rails 網站，也沒有塞了幾萬筆的資料庫，無法做出很精確的數據計算，大家看看就好，了解我論點的點即可。
: 我手邊的 Ruby on Rails 隨便一個頁面，HTML檔案，圖片加上 CSS ，
: 大概拉哩拉紮 100K ~ 500K 都很正常，
: 以一般 ADSL 全速來說 250K/s ，大概是 1 ~ 2 sec 可以處理完 。

  網頁是先傳 HTML（CSS）的資料
  然後 browser 才依據裡頭敘述再去要求 resource

  （扣掉 proxy, local cache, 網路傳輸壅塞、
    app. Server 要動態產生圖檔、ajax 等議題
    因為 giive 大大也沒有考慮這些變因）
  也就是說，真正的畫面上開始有回應的資料，應該是單純論純文字資料
  靜態圖片應該是歸 web server 處理時間，也不應該參雜進來一起計算

  我想，單純 HTML 碼平均算 100K 應該還在合理範圍？
  （遑論動態產生出的資料越多，RoR 的處理時間也應該正比提昇）
  那麼下面的講法

: Web Server 處理時間除非是大量的 request，否則我都當他是不需要處理時間。
: 根據 log 顯示，Ruby on Rai: ls 處理通常在 0.03 ~ 0.05 秒 之內完成。DB query 的時間，因為我現在的 Database 只有短短的數百筆（還沒開發完成呀），所以只能說 Database 時間目前是趨近於 0.005 秒左右的處理時間。
: 以目前這個正在開發中的頁面來說
: 我們可以發現就算是 Database 時間取的相當小，
: Ruby on Rails 佔總共回應時間的比例也相當少。
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  也就似乎不是太合乎客觀的記量方式？
  （簡言之就是... 我不覺得是佔 3% 而已）

: 使用其他更快的語言，3%變成 1%又如何 ，對於整體時間的加速也相當的有限。


: 依照我的經驗，一般不算影音檔的網站，整體時間的比例大概為
:    1. 網路傳遞時間 40%
:    2. Web Server 處理時間 15%
:    3. Application Server處理的時間 10%
:    4. DB 處理的時間 35%
: 這個比例完全沒有經過統計，純粹是我以前的經驗的感覺。
: 如果網路傳遞時間不考慮，一般來說，當網站越來越大時，
: 第一個遇到的 Bottleneck 通常都是在資料庫，
: 再來就是 Web Server 的處理能力會越來越重要（耗費記憶體會越多），
: 最後才是 Application Server 的問題。
: 也就是說ꄺ A Ruby on Rails 的速度重不重要，其實也還好。
: 就回應時間的比例來說，Application Server 的速度
: 其實不是能夠影響整體效率的關鍵 。
: 但是開發框架的開發時間長短，才是Application Server 最重要的事情，
: 不然你幹嘛不用 C 寫 CGI 就好？

  上面其實只是數據上的問題，其實 giive 大大的論點並沒有太大的問題

  但是，開發時間的長短才是 App. Server 最重要的事情
  這點，我實在感覺到非常的恐慌

  我沒寫過 CGI，所以這樣子說似乎不太準確
  不過根據我看過的書上都說，
  CGI 針對每一個 request 產生一個 process 去處理他
  相對於後來的 JSP（其他語言我不清楚）是用 thread 去處理
  在 overhead 上頭減輕取多，所以 CGI 本質上就比較慢
  在此拿 CGI 的例子來強調開發時間長短才是最重要的實情
  在下不才，但是甚感不妥

  如果 giive 大大有設定前提假設：
        1. 學術性質、而非商業性質
        2. 私人小型站台，心血來潮就修改功能
  簡言之就是需要應付需求變更快速，實做出功能甚於一切
  又或是像當年 JVM 對抗 C 的講法：
        3. 未來硬體會針對 JVM 作最佳化
  那或許 giive 大大的論點還能成立

  開發是一次性的成本
  寫完 deploy 上去，要應付多少年多少次的 request，誰能保證？
  這之間累積消耗的 resource 差異、對應到成本差異
  真的可以像 giive 大大說得輕鬆，一筆勾銷？

  在下真的不才，但也真的甚感不妥


  懇請指教

--
       侃侃長論鮮窒礙          網站：http://www.psmonkey.idv.tw
       眾目睽睽無心顫          個人版：telnet://legend.twbbs.org
       煢居少聊常人事   
       殺頭容易告白難          歡迎參觀 Java 版（@ptt.cc）精華區  \囧/

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.228.197.180

> -------------------------------------------------------------------------- <

作者: giive (lala) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Thu Oct 19 08:05:41 2006

[束刪]
※ 引述《PsMonkey (痞子軍團團長)》之銘言：
: 先說，我壓根沒用過回血戒，也不知道怎麼用 C 寫 CGI
: 更重要的是，我不是打著捧 Java solution 反 Ruby solution 來回這篇
: 只是覺得其中幾個議題很怪異
沒問題，我還有一個更更更怪異的論點，只是還沒談而已
: ※ 引述《giive (lala)》之銘言：
: : 出自我的Blog
: : http://lightyror.blogspot.com/2006/10/ruby-on-rails.html
:   根據上面這段很多問號的文章
:   基本上，Ruby 處理比較漫，這是公認的（至少，不是我說得 XDXD）
問號很多是因為那是簡體字
BBS先天的缺陷 XD
: : 大致上就是這四個地方。
:   我對 TCP/IP 還有 HTTP 通訊協定也不熟
:   （咪的，除了嘴泡，你有啥是熟的？）
:   但是，把網路傳輸時間（以 client 的網路速度來計算）
:   與 Server 運算時間合併來評估 RoR 的運算效率其實不那麼重要
:   略感奇怪...
:   （那麼，直接要求 RoR 跑在一台較高速的電腦，
:     效率問題不就更不那麼重要？）
沒錯 XD
:   網頁是先傳 HTML（CSS）的資料
:   然後 browser 才依據裡頭敘述再去要求 resource
:   （扣掉 proxy, local cache, 網路傳輸壅塞、
:     app. Server 要動態產生圖檔、ajax 等議題
:     因為 giive 大大也沒有考慮這些變因）
:   也就是說，真正的畫面上開始有回應的資料，應該是單純論純文字資料
:   靜態圖片應該是歸 web server 處理時間，也不應該參雜進來一起計算
:   我想，單純 HTML 碼平均算 100K 應該還在合理範圍？
:   （遑論動態產生出的資料越多，RoR 的處理時間也應該正比提昇）
是的，不過考慮那些東西已經太複雜了
所以一切的數據比例，我以 " 經驗 " 來推測
本來就是相當見仁見智的東西
:   那麼下面的講法
: : Ruby on Rails 佔總共回應時間的比例也相當少。
:   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:   也就似乎不是太合乎客觀的記量方式？
:   （簡言之就是... 我不覺得是佔 3% 而已）
你不覺得＠＠！，那我也沒辦法說有啥問題
單純以我這個頁面來說（就我這個case來說）
我覺得是 3%，我甚至可以跟你講 3% 是太高了
: : 使用其他更快的語言，3%變成 1%又如何 ，對於整體時間的加速也相當的有限。
: : 依照我的經驗，一般不算影音檔的網站，整體時間的比例大概為
: :    1. 網路傳遞時間 40%
: :    2. Web Server 處理時間 15%
: :    3. Application Server處理的時間 10%
: :    4. DB 處理的時間 35%
: : 這個比例完全沒有經過統計，純粹是我以前的經驗的感覺。
: : 如果網路傳遞時間不考慮，一般來說，當網站越來越大時，
: : 第一個遇到的 Bottleneck 通常都是在資料庫，
: : 再來就是 Web Server 的處理能力會越來越重要（耗費記憶體會越多），
: : 最後才是 Application Server 的問題。
: : 也就是說ꄺ A Ruby on Rails 的速度重不重要，其實也還好。
: : 就回應時間的比例來說，Application Server 的速度
: : 其實不是能夠影響整體效率的關鍵 。
: : 但是開發框架的開發時間長短，才是Application Server 最重要的事情，
: : 不然你幹嘛不用 C 寫 CGI 就好？
:   上面其實只是數據上的問題，其實 giive 大大的論點並沒有太大的問題
因為沒有統計的數據，所以我才用 " 經驗 "
我不是拿經驗當免死金牌
而是我沒時間，也沒相對應資源去作精確的測試
你可以質疑我的經驗
但是，我不免會替我的經驗來護航（沒辦法，不想證明自己白活了XD）
這恐怕會陷入戰的無窮迴圈 XD

:   但是，開發時間的長短才是 App. Server 最重要的事情
:   這點，我實在感覺到非常的恐慌
:   我沒寫過 CGI，所以這樣子說似乎不太準確
:   不過根據我看過的書上都說，
:   CGI 針對每一個 request 產生一個 process 去處理他
:   相對於後來的 JSP（其他語言我不清楚）是用 thread 去處理
:   在 overhead 上頭減輕取多，所以 CGI 本質上就比較慢
:   在此拿 CGI 的例子來強調開發時間長短才是最重要的實情
:   在下不才，但是甚感不妥
:   如果 giive 大大有設定前提假設：
:         1. 學術性質、而非商業性質
:         2. 私人小型站台，心血來潮就修改功能
:   簡言之就是需要應付需求變更快速，實做出功能甚於一切
:   又或是像當年 JVM 對抗 C 的講法：
:         3. 未來硬體會針對 JVM 作最佳化
:   那或許 giive 大大的論點還能成立
:   開發是一次性的成本
:   寫完 deploy 上去，要應付多少年多少次的 request，誰能保證？
:   這之間累積消耗的 resource 差異、對應到成本差異
:   真的可以像 giive 大大說得輕鬆，一筆勾銷？
:   在下真的不才，但也真的甚感不妥
:   懇請指教

我無意否定你的說法
我提出一些想法，以及一個我覺得更離經叛道的觀點，大家不贊同沒關係

我將下面的文章寫在這
http://lightyror.blogspot.com/2006/10/ruby-on-rails-part-2.html

為什麼網頁伺服器上面軟體速度不重要？

1. 因為根據這篇的說法，Application Server佔的比例不大（又是我的經驗...>_<）

2. 因為當你的Ruby速率成為焦點之前，資料庫會先搶著成為焦點
   Application Server 可以分散，資料庫考慮資料同步問題，不容易分散
   往往第一個瓶頸會出現在資料庫（資料庫大小，能夠接收request 數量）

3. 現在網站的傳輸時間所佔比例只會更多，不會更少
   相簿，影音網站當道，傳輸量動則上 MB
   Application Server 的速度比例會繼續下滑

最後一個觀點，也是我一直覺得會被戰的觀點

不管你喜不喜歡這個詞，網站已經進入 Web 2.0 的時代
Web 2.0 可說是一個最令人興奮，也最不負責任的時代
永遠的 Beta 掛在網站 Logo 上面
代表的意義是，我們的功能很新，很有趣
但是網站掛掉了你自己負責
在這個時代裡
所有軟體開發的觀念全部被Web 2.0否定
不需要完整的 TEST ，交給使用者去幫我們 Debug
只為了一個字

        功能新穎

有了功能新穎的網站
才能抓住使用者的眼球，才能吸收更多的使用者
才能吸引投資者增資，抓住創投的心
這個時代的軟體開發框架，必須要 " 開發時間最快 "
因為你必須趕在對手之前提出新功能
繼續打敗你的對手
才能夠繼續留住你的使用者
留住你的投資者

或許那天真的遇到你說的情況
你用 Ruby on Rails 快速的開發時間開發出一個很好的網站
使用者很喜歡，你的網站流量已經很大了
Ruby on Rails 速度已經稱不住了
但是理論上來說
在撐不住之前，你的投資者看到你的網站的前景
他們已經增資，你有更多錢買更好更多的硬體
所以你的 Ruby on Rails 又變得可以撐的住

但是如果選用執行速度較快，開發時間過長的開發框架
你的功能研發速度輸給對手
所以在這個莫名其妙的 Web 2.0 時代
你不太有可能獲得更多太多使用者
流量根本也無法滿足上述的 Application Server 撐不住的情況
那你的投資者不會投資你.........

開發速度快 -> 推出新功能時間快 -> 使用者很喜歡 -> 流量大 -> 伺服器快要撐不住
-> 投資者增資 -> 買更好的硬體 -> 持續運作

開發速度慢 -> 推出新功能時間慢 -> 使用者不喜歡 -> 流量小 -> ?

在這個詭異的 Web 2.0 時代，Application Server 負擔的責任就是

        快速開發時間

因為有快速開發時間的需求，Ruby on Rails 才會那麼的爆紅
所以我一直提到快速開發時間很重要

        為什麼？

因為沒有快速開發時間，就沒有網站的增資 XD
就不能像 YouTube 一樣，脫手賺個天文數字
（越講好像越鼓吹不良風氣?）

最後要講到一件事情
根據一些外電報導
就算 JAVA 跟 PHP 比 Ruby 快
JAVA 的 Struts+Spring+Hibernate 以及 PHP 的 Symfony
在某些測試都比 Ruby on Rails 的速度來得慢 ( 是某些測試，目前也沒完整的測試）
語言的速度並不直接等於框架的速度
你語言速度快，實做出來的速度慢，那等於沒搭
（Hibernate 在某方面功能比 Active Record 強，不過應該也是這樣付出了效率的代價）
目前就我看到的比較來說
Active Record 是市面上兼具功能強大，速度不錯的 ORM 系統

以上就是我的觀點
大家批小力一點

--

  lighty RoR 是一個介紹 lighttpd , SQLite , Ruby and Rails 的 Blog
  http://lightyror.blogspot.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.102.91
※ 編輯: giive           來自: 61.218.90.242        (10/19 10:51)
推 yzugsr:我喜歡這個離經叛道 :)
> -------------------------------------------------------------------------- <

作者: PsMonkey (痞子軍團團長) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Thu Oct 19 19:12:52 2006

原文我就全刪除了...
直接挑著講比較白刀子進紅刀子出一點  \囧/

基本上，我們都同意

        a. 如果在小型網站、需要快速回應需求變更
           那麼開發效率的確比語言的處理速度還要重要的多

        b. 如果提供較佳的環境（較充裕的 resource）
           那麼語言處理的速度，差異量就較小

        c. 運算部份的主要效能瓶頸是在 Database

先備註一下：我同意 b，但不代表我認同 b 的作法


下面就是我們的衝突點...

        1. 你提了數據，然後用數據去推論你要的結果
           問題是你的數據來源只是你的經驗
           （還是「感覺」出來的經驗，可信度本身就很可議）
           我也提了一些你計量方面的問題點
           例如：你一直把使用者的「總等待時間」當分母
           然後把 application server 的處理時間當分子
           我覺得這樣子很有問題，你好像沒有針對這點回應
           反而只回說：「我覺得 3% 還可能太高」

           資訊領域不就是特別強調 GIGO 嗎？
           現在連推論過程也覺得怪怪的
           除非你能指出我質疑點的缺失、或是那些質疑壓根不重要
           不然，我真的不知道怎麼看待你文章當中提到的數據以及推論？


        2. 你用一個很簡化的方法來處理「所有」的軟體開發
           Web 2.0 我不熟，但我可以很肯定
           Web 2.0 （以及你說的開發方式）
           絕對不是（不適用）軟體開發的全部，甚至可以縮小範圍，
           Web 2.0 （以及你說的開發方式）
           絕對不是（不適用） web programming 的全部

           我可以很輕易的舉出一個反例：不可能會有 Beta 版的電子商務網站

           可是你的兩篇文章卻似乎沒打算明確規範前提假設
           （也就是最上頭的 a）
           甚至感覺是想要推廣到所有種類的軟體開發
           最後要大家直接以「開發速度 vs 處理速度」的議題上選邊站
           我覺得這樣子的立論似乎也有欠周全



當然，還有一些我... 算是私人的困惑，
（也就是，不一定是你提出來的論調）
就是：

        →Ruby, RoR 開發「比較快」，這個的討論基礎是什麼？
          同樣是對程式概念模糊的新手？
          還是已經會寫程式（例如用 C 寫過一些 app）來使用新的語言
          去實做一個 project？
          還是對兩種語言已經專精的人，同時寫一個 project？

          我沒記錯的話，版上有 po 過最後這種類型的比賽
          但是，還是那個問題，夠客觀嗎？

        →我們能對效率這件事情，能抱持寬鬆的態度到哪種極限？
                「開發速度優先」、
                「別地方的瓶頸效應會比這裡明顯」、
                「倚賴更好的 computing resource」
          在這些論調之下，東西做出來就好
          那是不是可以不用在鳥演算法那些複雜度計算方式？

          說真的，這真的是跟資訊系教的理念完全背道而馳


=====
好了，我大致上講完了...
這次語氣比較沒有那麼卑躬屈膝（路人：虛偽的傢伙 [指]）
還請 giive 大大容忍一下...

我真的沒有要反 Ruby、也不是故意要來找碴
只是希望證明「Ruby 是良好的開發工具」的過程，能夠嚴謹一點

畢竟... 這裡不是虎爛版
廣告式的文案大家應該也看到麻木了....

以上... [擺茶點]

--
       侃侃長論鮮窒礙          網站：http://www.psmonkey.idv.tw
       眾目睽睽無心顫          個人版：telnet://legend.twbbs.org
       煢居少聊常人事   
       殺頭容易告白難          歡迎參觀 Java 版（@ptt.cc）精華區  \囧/

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.136.153.114
推 retsamsu:說真的，這真的是跟資訊系教的理念完全背道而馳
→ retsamsu:其實說真的，出了社會以後真的很多開發系統的概念跟
→ retsamsu:在學校學的理念都不太一樣，快速開發是一定要達成的目
→ retsamsu:標...某主管說做好5-6成就可上線維運了@@
> -------------------------------------------------------------------------- <

作者: giive (lala) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Thu Oct 19 20:03:10 2006

※ 引述《PsMonkey (痞子軍團團長)》之銘言：
: 原文我就全刪除了...
: 直接挑著講比較白刀子進紅刀子出一點  \囧/
: 基本上，我們都同意
:         a. 如果在小型網站、需要快速回應需求變更
:            那麼開發效率的確比語言的處理速度還要重要的多
:         b. 如果提供較佳的環境（較充裕的 resource）
:            那麼語言處理的速度，差異量就較小
:         c. 運算部份的主要效能瓶頸是在 Database
: 先備註一下：我同意 b，但不代表我認同 b 的作法
: 下面就是我們的衝突點...
:         1. 你提了數據，然後用數據去推論你要的結果
:            問題是你的數據來源只是你的經驗
:            （還是「感覺」出來的經驗，可信度本身就很可議）
:            我也提了一些你計量方面的問題點
:            例如：你一直把使用者的「總等待時間」當分母
:            然後把 application server 的處理時間當分子
:            我覺得這樣子很有問題，你好像沒有針對這點回應
:            反而只回說：「我覺得 3% 還可能太高」
:            資訊領域不就是特別強調 GIGO 嗎？
:            現在連推論過程也覺得怪怪的
:            除非你能指出我質疑點的缺失、或是那些質疑壓根不重要
:            不然，我真的不知道怎麼看待你文章當中提到的數據以及推論？

恩，第一個我沒有辦法做出這個時間比例
因為我根本沒有相關的資源去作推（懶得作也是實情啦）
所以我只好信任我的經驗
你要問我有沒有根據
我只能跟你講沒有作過所謂的精確的實驗

:         2. 你用一個很簡化的方法來處理「所有」的軟體開發
:            Web 2.0 我不熟，但我可以很肯定
:            Web 2.0 （以及你說的開發方式）
:            絕對不是（不適用）軟體開發的全部，甚至可以縮小範圍，
:            Web 2.0 （以及你說的開發方式）
:            絕對不是（不適用） web programming 的全部
:            我可以很輕易的舉出一個反例：不可能會有 Beta 版的電子商務網站
:            可是你的兩篇文章卻似乎沒打算明確規範前提假設
:            （也就是最上頭的 a）
:            甚至感覺是想要推廣到所有種類的軟體開發
:            最後要大家直接以「開發速度 vs 處理速度」的議題上選邊站
:            我覺得這樣子的立論似乎也有欠周全

說實在話，我已經預設使用 Rails 是來開發網站
所以，我直接預設以開發網站來當作這個論點的環境
今天這個論點會發生
也是因為 Web 架構下的軟體實在有很多東西可以影響所謂的 response time
所以我們必須不能用 Ruby 的速度慢，一以蓋之

: 當然，還有一些我... 算是私人的困惑，
: （也就是，不一定是你提出來的論調）
: 就是：
:         →Ruby, RoR 開發「比較快」，這個的討論基礎是什麼？
:           同樣是對程式概念模糊的新手？
:           還是已經會寫程式（例如用 C 寫過一些 app）來使用新的語言
:           去實做一個 project？
:           還是對兩種語言已經專精的人，同時寫一個 project？
:           我沒記錯的話，版上有 po 過最後這種類型的比賽
:           但是，還是那個問題，夠客觀嗎？

就我本身的體驗來說
我用兩個工作天改寫了一個已經用 CakePHP 寫了兩週的 Project
還在第二天最後一個小時增加一個新功能
所以我的體驗是 5 : 1（我一週上班五天）
Beyound JAVA 裡面有提到某個人做出了 16 : 1 的開發時間

開發時間比實在太過見仁見智...
我體驗過這種巨大的差異，所以深信不疑

:         →我們能對效率這件事情，能抱持寬鬆的態度到哪種極限？
:                 「開發速度優先」、
:                 「別地方的瓶頸效應會比這裡明顯」、
:                 「倚賴更好的 computing resource」

我是開發速度優先

:           在這些論調之下，東西做出來就好
:           那是不是可以不用在鳥演算法那些複雜度計算方式？
:           說真的，這真的是跟資訊系教的理念完全背道而馳

當然不是，我們不要求所有地方一定要最好
並不代表我們不重視，只是有些地方更為重要

如果一個字串剖析程式要頗析 1G 的字串檔
那他的演算法一定要夠快
但是如果目的只是頗析一個簡單的 config
那你用啥演算法有差嗎？
要先搞清楚重點在哪邊
最佳化才有效率

同樣的，網站開發我重視

        開發時間 > 資料庫設計 > cache >> 程式語言效率

是因為第一個關係到錢，第二個關係到擴充彈性
而且 cache 設計的好，可以嚴重的影響網站效率
這是在 網站開發的商業環境下所做出的取捨

我認為的重點可能跟你不同
並不代表我反對你的點

: =====
: 好了，我大致上講完了...
: 這次語氣比較沒有那麼卑躬屈膝（路人：虛偽的傢伙 [指]）
: 還請 giive 大大容忍一下...
: 我真的沒有要反 Ruby、也不是故意要來找碴
: 只是希望證明「Ruby 是良好的開發工具」的過程，能夠嚴謹一點

我今天不會花時間來測試
因為我知道我手邊的資源作不出相關的測試
並且，我寧願把時間花在寫 Rails DOC ........

--

  lighty RoR 是一個介紹 lighttpd , SQLite , Ruby and Rails 的 Blog
  http://lightyror.blogspot.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.218.90.242

> -------------------------------------------------------------------------- <

作者: b6s (http://b6s.blogspot.com) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Fri Oct 20 03:18:12 2006

唔，沒有數據確實是很麻煩的事。
純粹就常理推論的話，只要套 Amdahl's law 就可以了。

我印象中也只有 Beyond Java 一書及其相關討論稍微提到，
因為 ActiveRecord 實作出來的 OR mapping 比 hibernate/spring 之類的機制快，
另外又省掉了很多讀寫 xml 檔的 I/O，
於是 RoR 現階段比某些 J2EE solution 快。

另一方面，動態頁面生成的那一段，恐怕是使用者最有感覺的部分；
而這部分，嗯，J2EE solution 一直都只能算是可接受的速度而已。
各家 servlet engine 可能要負點責任。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.105.131.104
推 qrtt1:servlet只有慢在第一次要compile time，倒是覺得慢的原因在
→ qrtt1:於極端的去藕合實作方式讓各元件獨立出來，而在通溝的時間上
→ qrtt1:要稍為付出一點代價。當然變成cluster會比較好一點xd
→ b6s:我應該寫 JSP engine. 不過其實我同意你的看法。
> -------------------------------------------------------------------------- <

作者: godfat (godfat 真常) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Fri Oct 20 16:00:58 2006


呃，覺得討論方向好像有點偏離了
我覺得 PsMonkey 想說的是評估的方式不太對，
而非指個人經驗不適當，或是數據不正確之類的
例如 PsMonkey 的這句話：

:   網頁是先傳 HTML（CSS）的資料
:   然後 browser 才依據裡頭敘述再去要求 resource

就純 HTML 來說，我個人是覺得 100k 就算是很肥大的網頁了
剛剛隨便抓了一個有 8 篇文章的討論頁面，約 80k 左右
一般網站應該不會有如討論板這種大量文字的頁面…？
再加上 AJAX 的緣故，傳輸量可以再降低許多。

而 giive 提到的：

: 我手邊的 Ruby on Rails 隨便一個頁面，HTML檔案，圖片加上 CSS ，
: 大概拉哩拉紮 100K ~ 500K 都很正常，

CSS 應該傳一次就好，圖片的話，應該再另外算才對…？
大多數應該也是傳一次就好，需要不斷 update 的傳輸應該不會太多

我想 PsMonkey 想說的應該是類似這些的，而非選擇 RoR 是否正確
當然，有可能是我誤會啦…畢竟我跟網頁真的很不熟，沒辦法談些什麼，
也很難知道一個人真正的想法。總之這些是我看那些文字給我的感覺。

*

我很認同 giive 所貼的這一系列文章（雖然好幾個在 BBS 上看都不是很方便）
這正是為社群帶來活力的相當推手，也可以增加社群外人之視野。
不過我也相當認同 PsMonkey 對他覺得有問題的地方提出疑問，
這也正是為社群帶來活力的另外一個推手。

只要討論不流於情緒化，不管討論的內容正確與否，我覺得對社群都是有幫助的
畢竟這裡不是放置論文的地方，也不是學習的殿堂，而是大家交換心得的地方。
有錯誤有指正，才能讓大家慢慢開拓視野與走向他自己覺得正確的道路。

我覺得網路有趣的地方，就是可以更容易地找到可以討論的對象
有想法都提出來，我覺得是很好的，倒也沒什麼干擾之類的問題…
畢竟每個人都是這個社群（廣義）的一份子

*

不過有幾句話我覺得…有一點點不是很妥當，例如

: 那跟 M$ 做的事情有什麼差別？

質疑的感覺過於強烈 @@

: 抱歉，看來我沒必要跟你對話了

這好像有點太兇了… @@

: 又何必去干擾呢?

這有一點排外的感覺 @@

*

以上大概就是我這樣看下來的一點想法
純粹只是一個人的想法而已 :)
最不希望看到不歡而散，局中人和旁觀者都不會開心

--
In Lisp, you don't just write your program down toward the language,
         you also build the language up toward your program.

  《Programming Bottom-Up》－ Paul Graham 1993

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.117.166.29
推 b6s:Can not agree with you more.
> -------------------------------------------------------------------------- <

作者: 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
推 qrtt1:唔,這裡的EJB是指3.0之前嗎? 好奇地問
→ kojilin:不管是不是3.0囉,3.0之後是有變好寫,但是效能上
→ kojilin:畢竟是在EE Application Server上跑,提供的服務一多
→ kojilin:效能上就一定會拖累到~
推 qrtt1:嗯, 同感。剛剛突然想起了jdo google了一下，已經看到被稍為
→ qrtt1:dead-end 了.... 真可憐啊>"<
推 PsMonkey:啥？ JDO 掰掰了？這這這... 好棒阿...(還好當初沒買書)
→ qrtt1:只是有人覺得@@ 是不是8181 天曉得
→ kojilin:沒掰吧..bea的kodo也在..只是沒有另外兩家有聲勢罷了~
> -------------------------------------------------------------------------- <

作者: kojilin (呵呵呵噗噗噗..搞笑..) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Sat Oct 21 11:00:08 2006

※ 引述《giive (lala)》之銘言：
: ※ 引述《qrtt1 (愚者)》之銘言：
: :         蝸牛角上爭何事，石火光中寄此生
: 沒辦法＠＠！
: 我爭的是 " 在網頁開發中，開發時間遠比程式效能重要的多了 "
: PS先生爭的是 " 必須拿出相關證據，證明我的論點正確 "
: 我只好回 " 要數據沒有，要命一條XD "
: 不過說真的啦
: 每次一有類似這樣輸贏的數據出現
: 輸的一方總是叫 " 你的數據不正確 "
: 然後又作了一個數據，可以逆轉這個結果
: 贏的一方總是回 " 不敢認輸優 ，馬上又回你作的才不正確 "
: 曾幾何時，benchmark 的功用已經跟選舉的民調一樣
: 各方提出來得 benchmark 總是比較偏袒自己...
: 然後總是陷入戰的無窮迴圈 XD
沒錯:)
開發速度這東西根本沒法比較
我兩個都寫,但是畢竟我經歷Java時間比較長,對我來說兩個都快
RoR對我來說同功能的東西可能快一到兩倍或多一點.
這邊以我來說好了

RoR讓我可以快速就進入開發功能的狀態,因為他不用在那邊處理一堆有的沒的
但是如果一些功能沒有就必須自己想辦法在處理

而Java對我來說,要先建構一開始的環境,這邊花時間,有時還要翻一堆文件orz..
但是到加功能的動作上時
速度就會快很多.
尤其當你把架構定義明確時,其實就是在一直套之前的pattern加上功能.


其實要看開發系統針對的目標吧:)譬如現在大家喜歡說的Web2.0這類
標榜這類服務的site,就是必須開發的快,馬上釋出,迅速更新
所以看看一些有名Web2.0相關幾乎都是PHP or RoR
我之前有聽別人說過有一個是Java,所以比例上來說確實沒錯:P
就像如果現在要馬上寫個跟資料庫有關的系統
用Hibernate跟用AR相比,就要多個步驟先寫設定檔案
然後呢可能又得注意一下hibernatesession之類的東西
光這些就讓我有點小懶了XD..


koji

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.167.165.115

> -------------------------------------------------------------------------- <

作者: b6s (http://b6s.blogspot.com) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Sat Oct 21 13:35:21 2006

我同意其他的部分都有可議之處，事實上我覺得「詮釋」是一回事，能否找出什麼情況下
誰比較好用以利選擇，才是對一般開發者有幫助的事。

以下這一段我有些疑問。

※ 引述《kojilin (呵呵呵噗噗噗..搞笑..)》之銘言：
: 所以就算有效能瓶頸,這部分不太會是重點.
: 讓小弟提供個數據:)
: 動態產生頁面的部分,像我自己管的
: 透過google analytics,平日一天七萬page,人數大概快萬.
: 而同台機器上除了跑forum之外還有另外兩個service
: 當然另外兩個流量不大所以只統計了forum部分
: 這樣forum的平均處理時間也只有40~100ms

雖然評估效能的指標是時間，可是這裡的平均處理時間的量級看起來比較像 CPU time?
由於您是以 Google Analytics 的數據來作除法（是吧？），所以我有點困惑。

: 至少他不是 "只能算是可接受的速度而已"

我有一陣子沒比較特定應用程式了，只能說，一年以前，同樣用途的系統，例如，Wiki，
在同樣的機器上，Java based solution 切換網頁時反應都慢了一點點。之所以沒有明確
數據是因為，當時只要用用看，就感覺得出來。

今天，我又去逛了幾個勉強可資比較的系統，例如說用 Jive 和別人比，用 Xwiki 和別人
比，等等。它們很明顯地都已變快到必須實際測量才知道有沒有差異的程度了。只是使用
者感覺到的 wall clock time 仍然不像是 40~100ms 那種等級，大約要放大個十倍吧？

回到本討論主題的初衷，也許不是 benchmark 是否淪為行銷工具的問題，畢竟這世界上
是有 spec.org 的。與其要想辦法在 RoR 與 J2EE 之間分個高下，我個人更希望 JRuby
或 Groovy 之類的東西能對雙方都有益處。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.109.19.234
※ 編輯: b6s             來自: 140.109.19.234       (10/21 13:37)

> -------------------------------------------------------------------------- <

作者: kojilin (呵呵呵噗噗噗..搞笑..) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Sat Oct 21 16:30:21 2006

※ 引述《b6s (http://b6s.blogspot.com)》之銘言：
: 我同意其他的部分都有可議之處，事實上我覺得「詮釋」是一回事，能否找出什麼情況下
: 誰比較好用以利選擇，才是對一般開發者有幫助的事。
: 以下這一段我有些疑問。
: ※ 引述《kojilin (呵呵呵噗噗噗..搞笑..)》之銘言：
: : 所以就算有效能瓶頸,這部分不太會是重點.
: : 讓小弟提供個數據:)
: : 動態產生頁面的部分,像我自己管的
: : 透過google analytics,平日一天七萬page,人數大概快萬.
: : 而同台機器上除了跑forum之外還有另外兩個service
: : 當然另外兩個流量不大所以只統計了forum部分
: : 這樣forum的平均處理時間也只有40~100ms
: 雖然評估效能的指標是時間，可是這裡的平均處理時間的量級看起來比較像 CPU time?
: 由於您是以 Google Analytics 的數據來作除法（是吧？），所以我有點困惑。
我們系統後端有頁面處理時間的Log,會提供人數是要表達
像JavaEye的用戶數跟主機
我們用戶數稍微多一點點,主機稍微差一點點,但是處理速度仍然不差
並非直接拿什麼東西除以什麼
: : 至少他不是 "只能算是可接受的速度而已"
: 我有一陣子沒比較特定應用程式了，只能說，一年以前，同樣用途的系統，例如，Wiki，
: 在同樣的機器上，Java based solution 切換網頁時反應都慢了一點點。之所以沒有明確
: 數據是因為，當時只要用用看，就感覺得出來。
: 今天，我又去逛了幾個勉強可資比較的系統，例如說用 Jive 和別人比，用 Xwiki 和別人
: 比，等等。它們很明顯地都已變快到必須實際測量才知道有沒有差異的程度了。只是使用
: 者感覺到的 wall clock time 仍然不像是 40~100ms 那種等級，大約要放大個十倍吧？
: 回到本討論主題的初衷，也許不是 benchmark 是否淪為行銷工具的問題，畢竟這世界上
: 是有 spec.org 的。與其要想辦法在 RoR 與 J2EE 之間分個高下，我個人更希望 JRuby
: 或 Groovy 之類的東西能對雙方都有益處。
我為何提到處理時間
是剛好看到javaeye同樣也提供了rails處理時間
如果要加上使用者的"感覺"那就必須想到原po提到的瓶頸在哪
可能是網路傳輸時間,DB效能..等等,就像javaeye說他非常快,
但是對於在台灣的我來說
連大陸我覺得不算快:)所以你的評估點在哪裡呢?
如果加上各種環境因素,我想這就不是你要表達的
因為你提到了"J2EE solution一直只能算是可接受的速度而已"
而我也只是想回應妳這句,Java並不慢,如此罷了

用Jive,以前我們論壇也用過
我也覺得他不難用,
尤其那時還在p3-450的電腦
雖然流量沒很大但是也是不錯的速度
我不認為Jive會慢

所以到底,我只是想提一下Java的系統
還是要看設計的如何,而不是單純就是一句話就說"他很慢"~

我想我的這幾篇文章應該沒有要分高下的意思,如果有我應該會去回giive的文章XD
而且我覺得他說的也沒有錯誤,有些人在意的是開發速度
有些人在意的是系統的速度,如果他評估過後取捨其中一個
那麼就沒有什麼錯誤

外加任何人都會注重這兩樣東西,只是比重不同罷了
不然為何大家會希望Ruby可以更快一點,
而Java這邊也開始仿效RoR,開始一堆fullstack的framework.


koji

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.167.165.115
推 godfat:推
> -------------------------------------------------------------------------- <

作者: b6s (http://b6s.blogspot.com) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Sat Oct 21 18:53:37 2006

※ 引述《kojilin (呵呵呵噗噗噗..搞笑..)》之銘言：
: 我為何提到處理時間
: 是剛好看到javaeye同樣也提供了rails處理時間
: 如果要加上使用者的"感覺"那就必須想到原po提到的瓶頸在哪
: 可能是網路傳輸時間,DB效能..等等,就像javaeye說他非常快,
: 但是對於在台灣的我來說
: 連大陸我覺得不算快:)所以你的評估點在哪裡呢?
: 如果加上各種環境因素,我想這就不是你要表達的
: 因為你提到了"J2EE solution一直只能算是可接受的速度而已"
: 而我也只是想回應妳這句,Java並不慢,如此罷了

我仍然覺得有些困惑。
所以您的「處理時間」是像 JavaEye 的分類法那樣，去掉 DB 的部分，當然也不算網路？

以前我自己測東西的時候，為了讓整個 wall clock time 最接近使用者的感覺，
會想辦法走 localhost 或在區域網路內，用 MS Web Application Stress Tool 去打，
通常，我的評估點是這樣來的。

若純粹回到 JavaEye 定義的處理時間，他說：
「根據 log 顯示，Ruby on Rails 處理通常在 0.03 ~ 0.05 秒 之內完成。」
這與您提到的數字的量級還算接近。

當然我同意，Java 並不慢，但就我最近半年學習 Tapestry 4.0 並以上述方法測試的
結果看來，恐怕還是「可接受」而不是快。原因或許也真如另一位網友所言，不少去藕合
的元件溝通成本高了一點點。因為我不用 OR mapping 只用 apache jdbc pool，以上述方
式從 local 進行壓力測試，比較對象為 model 仍採用 apache library 但前端全部換成
PHP 的作法。這也是先前我為什麼說似乎是前端處理部分讓人最有感覺的理由。沒有在之
前就講清楚，在此向大家道歉。<(_ _)>

啊，說穿了，這只是個案。所以其實我對誰快誰慢不是真那麼在乎。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.105.131.104
※ 編輯: b6s             來自: 59.105.131.104       (10/21 18:56)
※ 編輯: b6s             來自: 59.105.131.104       (10/21 18:58)

> -------------------------------------------------------------------------- <

作者: kojilin (呵呵呵噗噗噗..搞笑..) 看板: Ruby
標題: Re: Ruby on Rails 的速度議題
時間: Sat Oct 21 19:59:09 2006

※ 引述《b6s (http://b6s.blogspot.com)》之銘言：
: 我仍然覺得有些困惑。
: 所以您的「處理時間」是像 JavaEye 的分類法那樣，去掉 DB 的部分，當然也不算網路？
: 以前我自己測東西的時候，為了讓整個 wall clock time 最接近使用者的感覺，
: 會想辦法走 localhost 或在區域網路內，用 MS Web Application Stress Tool 去打，
: 通常，我的評估點是這樣來的。
: 若純粹回到 JavaEye 定義的處理時間，他說：
: 「根據 log 顯示，Ruby on Rails 處理通常在 0.03 ~ 0.05 秒 之內完成。」
: 這與您提到的數字的量級還算接近。
我確實沒有用stress tool測試過
只看log,而log是實際現在上線,從收到request到response的時間
所以是包含db的.當然..這沒有網路傳輸時間.
有機會我在試試看有沒有辦法使用stress tool測試了,因為現在機器不是放在身邊
: 當然我同意，Java 並不慢，但就我最近半年學習 Tapestry 4.0 並以上述方法測試的
: 結果看來，恐怕還是「可接受」而不是快。原因或許也真如另一位網友所言，不少去藕合
: 的元件溝通成本高了一點點。因為我不用 OR mapping 只用 apache jdbc pool，以上述方
: 式從 local 進行壓力測試，比較對象為 model 仍採用 apache library 但前端全部換成
: PHP 的作法。這也是先前我為什麼說似乎是前端處理部分讓人最有感覺的理由。沒有在之
: 前就講清楚，在此向大家道歉。<(_ _)>
: 啊，說穿了，這只是個案。所以其實我對誰快誰慢不是真那麼在乎。
我自己沒碰過tapestry,所以我不知道tapestry是否這麼慢
還是原因出在哪部分,或者你的壓力測試確實讓Java寫的系統無法承受
既然是個案我想我也沒辦法提供什麼好方法幫你改進或有辦法用說的就讓你覺得快XD
我只是想幫忙平反"J2EE solution 一直都只能算是可接受的速度而已":P
"個案"怎麼會推到"一向"呢?
嗯~我沒有意思抓小辮子或失言怎樣,
只是想表達一下也是有人很"滿意"的.


koji

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.167.165.115
推 b6s:「一向」一辭確實不當。寫下那段時我腦中浮現的是一些經驗：
→ b6s:四年前測 servlet engines 的 HTTP request,
→ b6s:三年前測 SnipSnap 和 Jive，兩年前測 Xwiki，今年測 Tapestry
→ b6s:看來最近應該要再來做些嚴謹的測試了，不然總是一些模糊的回憶
推 qrtt1:囧. 樓上測完如果有餘力寫點文章去發表:p 不然太可惜了