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