Ruby on Rails 的速度議題

剛剛看了 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 倍）

今晚，你要選那道菜？