Re: Ruby on Rails 的速度議題

看板Ruby作者PsMonkey (痞子軍團團長)時間18年前 (2006/10/18 23:06)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串2/19 (看更多)

先說，我壓根沒用過回血戒，也不知道怎麼用 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 大大說得輕鬆，一筆勾銷？在下真的不才，但也真的甚感不妥懇請指教 : 你可以選擇一個速度可以接受，開發時間可以更上一層樓的框架，或是接受一個速度不錯，開發時間多個 1 ~ 2 倍的框架（根據各方報導，開發時間差個 2倍還是低估了，一般Ruby on Rails體驗者通常是說 4 ~ 7 倍） : 今晚，你要選那道菜？ -- 侃侃長論鮮窒礙網站：http://www.psmonkey.idv.tw 眾目睽睽無心顫個人版：telnet://legend.twbbs.org 煢居少聊常人事殺頭容易告白難歡迎參觀 Java 版（@ptt.cc）精華區 \囧/ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.228.197.180