出自我的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