原文地址： http://2byte.us/2013/rails-is-too-much-not-so
说 Ruby，如果没有带上 on Rails，总觉的缺点什么。或许从侧面说明了 rails 对于 ruby 的重要。
几乎从来没有见过哪个框架在某个语言有 rails 这样的统治地位。通常认为“垄断”不好，但 rails 的垄断地位是自己争来的，如果没有持续活跃和专业的社区，没有出色的发行版，rails 不可能这么受欢迎。
最常听到对 rails 的抱怨是性能上的，内存占用问题，多线程问题，加载了太多的组件，真的是这样么？
Ruby 是解释语言，很占内存？
某种意义上，是的。解释性语言通常比编译语言更占内存。但使用解释性语言就是因为它的轻便灵活。Ruby 的内存机制亦非常重视这一点。因此，评价 Ruby 的内存状况和使用的 vm 关系极大。
如果简单点说，Ruby 1.8 以前版本内存消耗严重，非 RubyEE 几乎是不能用于生产环境的。1.9.3 以后版本对内存管理有非常好的优化，直观上占用可降低 50% 以上，甚至胜过号称超过 MRI30% 的 RubyEE。 http://nerds.airbnb.com/upgrading-from-ree-187-to-ruby-193/
具体的比较在这里： http://blog.pothoven.net/2012/10/ruby-187-vs-193-performance.html
Rails 加载了太多东西，很慢？
Rails 是加载了不少东西，但是其一：其对性能影响对于访问量有限的网站并不显著；其二，可以定制加载，去掉不用的组件，比如使用 MongoDB，就可以完全移除 ActiveRecord，这并不是什么太麻烦的事情。
Rails 不适合做 Mobile Web？
No, No Rails 或许不如 Sinatra 适合 API 型的应用，但对于 Mobile，本身也是 Web，确实没有什么水土不符的。如果觉得访问缓慢，或许应该考虑更多是代码逻辑或者部署配置。如果应用没有用到任何缓存，每次都调用几十次查询，那么用 C 也救不了。
应用开发者或许更了解操作系统和代码逻辑，对 Web 优化了解很少。Rails 提供了不少工具，好好读读 Rails Guide 中 assets 和 cache 相关章节，会收益良多。
Rails 做了很多，其中大多数是有用的
Rails 已经不仅仅是 Ruby 一家的框架了。它几乎可以无代价的集成 coffeescript, haml, less, sass... 这个列表可以无限制的列下去，甚至你自己的 DSL 也可以。
Rails 3 开始加入的 assets pipe 绝对是神作，前端优化变成了傻瓜式操作。coffeescript 作为去年发展最快的奇迹性语言，终于让 javascript 不那么笨了。haml 节省了 50% 的 HTML 代码，优雅而简单。
如果不是 rails，可能其中的一些不会那么快的推广普及。作为最有活力的社区之一，rails 非常开放，能够快速接受新技术。
最重要的是：做出产品，而不是纠结每秒多处理几次请求
Rails 成为创业公司最爱是有原因的，对于创业公司，执行力是最值钱的。
云时代，添置硬件就能解决的吞吐问题，在开始阶段都不是问题。为了提升一倍性能，花数月研究测试框架组件，给自己挖坑，还是每月多花几百块添多一台服务器？这应该是很简单的问题。
正好昨天有查一些相关资讯，这里来作些反证： Wordpress 通常装了外挂以后会用 30 mb 以上的记忆体。 要是用 Rails 架设一个 blog 一定都 60 mb 起跳。 以这个需求来看 RoR 还是重 PHP App 一阶。
robbin 的http://robbinfan.com/blog/40/ruby-off-rails中提到： Rails 调用堆栈过深，URL 请求处理性能很差
Rails 的设计目标是提供 Web 开发的 最佳实践，所以无论你需要不需要，Rails 默认提供了开发 Website 所有可能的组件，但其中绝大部分你可能一辈子都用不上。例如 Rails 项目默认添加了 20 个 middleware，但其中 10 个都是可以去掉的，我们自己的项目当中手工删除了这些 middleware：
config.middleware.delete 'Rack::Cache' # 整页缓存，用不上 config.middleware.delete 'Rack::Lock' # 多线程加锁，多进程模式下无意义 config.middleware.delete 'Rack::Runtime' # 记录 X-Runtime（方便客户端查看执行时间） config.middleware.delete 'ActionDispatch::RequestId' # 记录 X-Request-Id（方便查看请求在群集中的哪台执行） config.middleware.delete 'ActionDispatch::RemoteIp' # IP SpoofAttack config.middleware.delete 'ActionDispatch::Callbacks' # 在请求前后设置 callback config.middleware.delete 'ActionDispatch::Head' # 如果是 HEAD 请求，按照 GET 请求执行，但是不返回 body config.middleware.delete 'Rack::ConditionalGet' # HTTP 客户端缓存才会使用 config.middleware.delete 'Rack::ETag' # HTTP 客户端缓存才会使用 config.middleware.delete 'ActionDispatch::BestStandardsSupport' # 设置 X-UA-Compatible, 在 nginx 上设置 其中最夸张的是 ActionDispatch::RequestIdmiddleware，只有在大型应用部署在群集环境下进行线上调试才可能用到的功能，有什么必要做成默认的功能呢？Rails 的哲学是：提供最全的功能集给你，如果你用不到，你自己手工一个一个关闭掉，但是这样带来的结果就是默认带了太多不必要的冗余功能，造成性能损耗极大。
