先说，我压根没用过回血戒，也不知道怎麽用 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