Re: Ruby on Rails 的速度議題

看板Ruby作者giive (lala)時間18年前 (2006/10/19 07:09)推噓1(1推 0噓 0→)

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

[束刪] ※ 引述《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)