Rails到底能支撑多大的负载?靠多进程吗？

<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></iframe>

哈哈，程序员杂志的编辑们可要谨慎点，对岸的兄弟们也看这本杂志，对RoR的数据可要check清楚。其实我也是看了那期程序员杂志才决定不用RoR的。

lightyror.blogspot.com可对杂志里面提到的数字表示不满了：

Rails 的 High Traffic 负载度

看了对岸的 《程序员》10期特别策划：Web开发之华山论剑里面的评论，里面有一段（原文为简体，我直接翻译成繁体）

如 果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适，比如 37 Signal 开发的 Basecamp.com 和 Robot Co-op 开发的 43Things.com 采用 Rails，这些Web2.0 的小应用每天页面访问几十万，数据库纪录数不到百万，负载是比较轻的。

看完真是无言，43Things 最好 Traffic 那么少，根据 Alexa 的数据，43Things.com 的 Daily Reach 每天大约是 600 Million 。虽然 Alexa 的数据准确性有很多人质疑（我是很质疑这个数字啦），不过这个流量数要硬说成只有几十万也差太多了吧。

我列一下一些用 Ruby on Rails 的高 traffic 站台。我之所以用 Alexa 的原因是因为我不可能拿到下面站台的 Traffic 营运数据，所以我只能使用看似不是很准的 Alexa 来比较。

1. A List Part：Alexa 上面的数字最高冲到 1500 Million Day Reach ，已经是流量很不错的站台了，Daily Reach 今年一度到达国内 Webs TV 网站的一半。

2. Penny Arcade：Alexa 800 Million Daily Reach，数字是蕃薯藤新闻的两倍。

3. 43Things.com：今年上半年 Daily Reach 跟 A List Part 差不多，Alexa 数字是 600 Million Daily Reach，依照比例大概比蕃薯藤新闻多了一点Daily Reach。

4. Odeo.com：这个站依照 Alexa 大概也跟蕃薯藤新闻差不多，不过少了一点。他是 Podcast 声音档案的网站，频宽的消耗度是相当可怕。（虽然 Ruby on Rails 的覆载度跟 Handle 频宽的能力，没有直接关系XD）

5. Basecamp：让 Ruby on Rails 诞生的指标性网站， Daily Reach 大致上跟 Odeo.com 差不多。我有使用过一段时间，他的权限系统相当的复杂，不用 Ruby on Rails 那么简单的东西写会很难写。

6. Eins.de：虽然比他流量大的网站还很多，但是 procs.net 在这篇文章有特别讲到他的架构。软件使用纯 Open Source 的架构，硬件使用光华商场叫的到的货色，一天可以服务 1.2 Million 动态网页。对 Ruby on Rails 的高覆载度有问题吗，这篇文章可以打破你的疑惑。

7. Hemidemi：我所知道国内第一个 Ruby on Rails 网站，站长是我学长 XD，这一两个月成长开始爆发。

8. JaveEye：我最常举的例子，根据通过JavaEye2.0网站看ruby on rails性能这篇的说法，JavaEye 只用到一台光华商场买的到的机器，也就是 Web Server ，DB Server ，Mail Server ，Search Server 都在同一台。纯 Open Source 的架构，一天处理个 50 万应该没问题。

如果这些网站，还无法堵住『如果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适』这样的嘴，那么我也没话说了。因为 Ruby on Rails 很年轻，所以用 Ruby on Rails 开发的站台大多营运时间只有一年不到，一个新兴网站其实有上面那么多流量其实已经很吓人了。如果再过个一年，或许会有流量更惊人的 Ruby on Rails 网站出现。

最后，当网站负载度到达一定程度，任何语言都不能可能承担这样的流量，所以网站的负载度还是看彼此的架构好坏，不是取决于语言本身，绝对没有一个站台只靠 PHP 或是 CGI 就可处理所有Request 的。语言或是框架对于乘载度的差别在于『转换高流量负载架构的弹性』，这点 Ruby on Rails 作的真的不差。

PS. Measure Map 是用 Ruby on Rails 写的，已经被 Google 买下来。

=====

blabla，但是我还有一个疑问，Ruby的线程问题如何解释他能够支撑大负载呢？难道真的要靠多进程吗？

“JavaEye 有一篇文章 Ruby的伪线程，讲述的是 Ruby 在 Thread 的问题。当然 Thread 对于 Performance 对于效能的进步是有很大的帮助啦。不过目前 Ruby 上面最有希望的 Native Thread Virtual Machine ：YARV 目前处于缓步状态。
”

根据 Another Year, Another Interpreter 这篇文章，更是抛下一个震撼弹

And then Matz and Koichi dropped the bomb: Ruby 2.0 would support neither continuations nor green threads.

真是太惨了，看来 Thread 在 Ruby 还是遥遥无期。这时候，Ruby 社群应该把重心投入在 YARV 上面，还是刚刚传出大捷报的 JRuby 上面呢？毕竟 JRuby 是 Native Thread 的，目标也是可以在 JVM 上面跑 Ruby on Rails （目前 JRuby 确定可以跑 Active Record ）。这似乎是一个好选择，不过 Ruby 社群是不是愿意将所有筹码压宝在 JRuby 呢？JRuby 现在可是由SUN 这家商业公司所主导的。

当然就算 Ruby 支持 Thread ，也会有很多问题要解决。Rails 本身不是 Thread Safe 的，Zed Shaw （Mongrel 作者）也说 Meta Programming 有很多 Thread Safe Probelm 。总之，Thread on Ruby 是一个难题，短期内也应该不会有很好的解法。

哈哈，程序员杂志的编辑们可要谨慎点，对岸的兄弟们也看这本杂志，对RoR的数据可要check清楚。其实我也是看了那期程序员杂志才决定不用RoR的。

lightyror.blogspot.com可对杂志里面提到的数字表示不满了：

Rails 的 High Traffic 负载度

看了对岸的 《程序员》10期特别策划：Web开发之华山论剑里面的评论，里面有一段（原文为简体，我直接翻译成繁体）

如 果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适，比如 37 Signal 开发的 Basecamp.com 和 Robot Co-op 开发的 43Things.com 采用 Rails，这些Web2.0 的小应用每天页面访问几十万，数据库纪录数不到百万，负载是比较轻的。

看完真是无言，43Things 最好 Traffic 那么少，根据 Alexa 的数据，43Things.com 的 Daily Reach 每天大约是 600 Million 。虽然 Alexa 的数据准确性有很多人质疑（我是很质疑这个数字啦），不过这个流量数要硬说成只有几十万也差太多了吧。

我列一下一些用 Ruby on Rails 的高 traffic 站台。我之所以用 Alexa 的原因是因为我不可能拿到下面站台的 Traffic 营运数据，所以我只能使用看似不是很准的 Alexa 来比较。

1. A List Part：Alexa 上面的数字最高冲到 1500 Million Day Reach ，已经是流量很不错的站台了，Daily Reach 今年一度到达国内 Webs TV 网站的一半。

2. Penny Arcade：Alexa 800 Million Daily Reach，数字是蕃薯藤新闻的两倍。

3. 43Things.com：今年上半年 Daily Reach 跟 A List Part 差不多，Alexa 数字是 600 Million Daily Reach，依照比例大概比蕃薯藤新闻多了一点Daily Reach。

4. Odeo.com：这个站依照 Alexa 大概也跟蕃薯藤新闻差不多，不过少了一点。他是 Podcast 声音档案的网站，频宽的消耗度是相当可怕。（虽然 Ruby on Rails 的覆载度跟 Handle 频宽的能力，没有直接关系XD）

5. Basecamp：让 Ruby on Rails 诞生的指标性网站， Daily Reach 大致上跟 Odeo.com 差不多。我有使用过一段时间，他的权限系统相当的复杂，不用 Ruby on Rails 那么简单的东西写会很难写。

6. Eins.de：虽然比他流量大的网站还很多，但是 procs.net 在这篇文章有特别讲到他的架构。软件使用纯 Open Source 的架构，硬件使用光华商场叫的到的货色，一天可以服务 1.2 Million 动态网页。对 Ruby on Rails 的高覆载度有问题吗，这篇文章可以打破你的疑惑。

7. Hemidemi：我所知道国内第一个 Ruby on Rails 网站，站长是我学长 XD，这一两个月成长开始爆发。

8. JaveEye：我最常举的例子，根据通过JavaEye2.0网站看ruby on rails性能这篇的说法，JavaEye 只用到一台光华商场买的到的机器，也就是 Web Server ，DB Server ，Mail Server ，Search Server 都在同一台。纯 Open Source 的架构，一天处理个 50 万应该没问题。

如果这些网站，还无法堵住『如果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适』这样的嘴，那么我也没话说了。因为 Ruby on Rails 很年轻，所以用 Ruby on Rails 开发的站台大多营运时间只有一年不到，一个新兴网站其实有上面那么多流量其实已经很吓人了。如果再过个一年，或许会有流量更惊人的 Ruby on Rails 网站出现。

最后，当网站负载度到达一定程度，任何语言都不能可能承担这样的流量，所以网站的负载度还是看彼此的架构好坏，不是取决于语言本身，绝对没有一个站台只靠 PHP 或是 CGI 就可处理所有Request 的。语言或是框架对于乘载度的差别在于『转换高流量负载架构的弹性』，这点 Ruby on Rails 作的真的不差。

PS. Measure Map 是用 Ruby on Rails 写的，已经被 Google 买下来。

=====

blabla，但是我还有一个疑问，Ruby的线程问题如何解释他能够支撑大负载呢？难道真的要靠多进程吗？

“JavaEye 有一篇文章 Ruby的伪线程，讲述的是 Ruby 在 Thread 的问题。当然 Thread 对于 Performance 对于效能的进步是有很大的帮助啦。不过目前 Ruby 上面最有希望的 Native Thread Virtual Machine ：YARV 目前处于缓步状态。
”

根据 Another Year, Another Interpreter 这篇文章，更是抛下一个震撼弹

And then Matz and Koichi dropped the bomb: Ruby 2.0 would support neither continuations nor green threads.

真是太惨了，看来 Thread 在 Ruby 还是遥遥无期。这时候，Ruby 社群应该把重心投入在 YARV 上面，还是刚刚传出大捷报的 JRuby 上面呢？毕竟 JRuby 是 Native Thread 的，目标也是可以在 JVM 上面跑 Ruby on Rails （目前 JRuby 确定可以跑 Active Record ）。这似乎是一个好选择，不过 Ruby 社群是不是愿意将所有筹码压宝在 JRuby 呢？JRuby 现在可是由SUN 这家商业公司所主导的。

当然就算 Ruby 支持 Thread ，也会有很多问题要解决。Rails 本身不是 Thread Safe 的，Zed Shaw （Mongrel 作者）也说 Meta Programming 有很多 Thread Safe Probelm 。总之，Thread on Ruby 是一个难题，短期内也应该不会有很好的解法。

哈哈，程序员杂志的编辑们可要谨慎点，对岸的兄弟们也看这本杂志，对RoR的数据可要check清楚。其实我也是看了那期程序员杂志才决定不用RoR的。

lightyror.blogspot.com可对杂志里面提到的数字表示不满了：

Rails 的 High Traffic 负载度

看了对岸的 《程序员》10期特别策划：Web开发之华山论剑里面的评论，里面有一段（原文为简体，我直接翻译成繁体）

如 果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适，比如 37 Signal 开发的 Basecamp.com 和 Robot Co-op 开发的 43Things.com 采用 Rails，这些Web2.0 的小应用每天页面访问几十万，数据库纪录数不到百万，负载是比较轻的。

看完真是无言，43Things 最好 Traffic 那么少，根据 Alexa 的数据，43Things.com 的 Daily Reach 每天大约是 600 Million 。虽然 Alexa 的数据准确性有很多人质疑（我是很质疑这个数字啦），不过这个流量数要硬说成只有几十万也差太多了吧。

我列一下一些用 Ruby on Rails 的高 traffic 站台。我之所以用 Alexa 的原因是因为我不可能拿到下面站台的 Traffic 营运数据，所以我只能使用看似不是很准的 Alexa 来比较。

1. A List Part：Alexa 上面的数字最高冲到 1500 Million Day Reach ，已经是流量很不错的站台了，Daily Reach 今年一度到达国内 Webs TV 网站的一半。

2. Penny Arcade：Alexa 800 Million Daily Reach，数字是蕃薯藤新闻的两倍。

3. 43Things.com：今年上半年 Daily Reach 跟 A List Part 差不多，Alexa 数字是 600 Million Daily Reach，依照比例大概比蕃薯藤新闻多了一点Daily Reach。

4. Odeo.com：这个站依照 Alexa 大概也跟蕃薯藤新闻差不多，不过少了一点。他是 Podcast 声音档案的网站，频宽的消耗度是相当可怕。（虽然 Ruby on Rails 的覆载度跟 Handle 频宽的能力，没有直接关系XD）

5. Basecamp：让 Ruby on Rails 诞生的指标性网站， Daily Reach 大致上跟 Odeo.com 差不多。我有使用过一段时间，他的权限系统相当的复杂，不用 Ruby on Rails 那么简单的东西写会很难写。

6. Eins.de：虽然比他流量大的网站还很多，但是 procs.net 在这篇文章有特别讲到他的架构。软件使用纯 Open Source 的架构，硬件使用光华商场叫的到的货色，一天可以服务 1.2 Million 动态网页。对 Ruby on Rails 的高覆载度有问题吗，这篇文章可以打破你的疑惑。

7. Hemidemi：我所知道国内第一个 Ruby on Rails 网站，站长是我学长 XD，这一两个月成长开始爆发。

8. JaveEye：我最常举的例子，根据通过JavaEye2.0网站看ruby on rails性能这篇的说法，JavaEye 只用到一台光华商场买的到的机器，也就是 Web Server ，DB Server ，Mail Server ，Search Server 都在同一台。纯 Open Source 的架构，一天处理个 50 万应该没问题。

如果这些网站，还无法堵住『如果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适』这样的嘴，那么我也没话说了。因为 Ruby on Rails 很年轻，所以用 Ruby on Rails 开发的站台大多营运时间只有一年不到，一个新兴网站其实有上面那么多流量其实已经很吓人了。如果再过个一年，或许会有流量更惊人的 Ruby on Rails 网站出现。

最后，当网站负载度到达一定程度，任何语言都不能可能承担这样的流量，所以网站的负载度还是看彼此的架构好坏，不是取决于语言本身，绝对没有一个站台只靠 PHP 或是 CGI 就可处理所有Request 的。语言或是框架对于乘载度的差别在于『转换高流量负载架构的弹性』，这点 Ruby on Rails 作的真的不差。

PS. Measure Map 是用 Ruby on Rails 写的，已经被 Google 买下来。

=====

blabla，但是我还有一个疑问，Ruby的线程问题如何解释他能够支撑大负载呢？难道真的要靠多进程吗？

“JavaEye 有一篇文章 Ruby的伪线程，讲述的是 Ruby 在 Thread 的问题。当然 Thread 对于 Performance 对于效能的进步是有很大的帮助啦。不过目前 Ruby 上面最有希望的 Native Thread Virtual Machine ：YARV 目前处于缓步状态。
”

根据 Another Year, Another Interpreter 这篇文章，更是抛下一个震撼弹

And then Matz and Koichi dropped the bomb: Ruby 2.0 would support neither continuations nor green threads.

真是太惨了，看来 Thread 在 Ruby 还是遥遥无期。这时候，Ruby 社群应该把重心投入在 YARV 上面，还是刚刚传出大捷报的 JRuby 上面呢？毕竟 JRuby 是 Native Thread 的，目标也是可以在 JVM 上面跑 Ruby on Rails （目前 JRuby 确定可以跑 Active Record ）。这似乎是一个好选择，不过 Ruby 社群是不是愿意将所有筹码压宝在 JRuby 呢？JRuby 现在可是由SUN 这家商业公司所主导的。

当然就算 Ruby 支持 Thread ，也会有很多问题要解决。Rails 本身不是 Thread Safe 的，Zed Shaw （Mongrel 作者）也说 Meta Programming 有很多 Thread Safe Probelm 。总之，Thread on Ruby 是一个难题，短期内也应该不会有很好的解法。

哈哈，程序员杂志的编辑们可要谨慎点，对岸的兄弟们也看这本杂志，对RoR的数据可要check清楚。其实我也是看了那期程序员杂志才决定不用RoR的。

lightyror.blogspot.com可对杂志里面提到的数字表示不满了：

Rails 的 High Traffic 负载度

看了对岸的 《程序员》10期特别策划：Web开发之华山论剑里面的评论，里面有一段（原文为简体，我直接翻译成繁体）

如 果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适，比如 37 Signal 开发的 Basecamp.com 和 Robot Co-op 开发的 43Things.com 采用 Rails，这些Web2.0 的小应用每天页面访问几十万，数据库纪录数不到百万，负载是比较轻的。

看完真是无言，43Things 最好 Traffic 那么少，根据 Alexa 的数据，43Things.com 的 Daily Reach 每天大约是 600 Million 。虽然 Alexa 的数据准确性有很多人质疑（我是很质疑这个数字啦），不过这个流量数要硬说成只有几十万也差太多了吧。

我列一下一些用 Ruby on Rails 的高 traffic 站台。我之所以用 Alexa 的原因是因为我不可能拿到下面站台的 Traffic 营运数据，所以我只能使用看似不是很准的 Alexa 来比较。

1. A List Part：Alexa 上面的数字最高冲到 1500 Million Day Reach ，已经是流量很不错的站台了，Daily Reach 今年一度到达国内 Webs TV 网站的一半。

2. Penny Arcade：Alexa 800 Million Daily Reach，数字是蕃薯藤新闻的两倍。

3. 43Things.com：今年上半年 Daily Reach 跟 A List Part 差不多，Alexa 数字是 600 Million Daily Reach，依照比例大概比蕃薯藤新闻多了一点Daily Reach。

4. Odeo.com：这个站依照 Alexa 大概也跟蕃薯藤新闻差不多，不过少了一点。他是 Podcast 声音档案的网站，频宽的消耗度是相当可怕。（虽然 Ruby on Rails 的覆载度跟 Handle 频宽的能力，没有直接关系XD）

5. Basecamp：让 Ruby on Rails 诞生的指标性网站， Daily Reach 大致上跟 Odeo.com 差不多。我有使用过一段时间，他的权限系统相当的复杂，不用 Ruby on Rails 那么简单的东西写会很难写。

6. Eins.de：虽然比他流量大的网站还很多，但是 procs.net 在这篇文章有特别讲到他的架构。软件使用纯 Open Source 的架构，硬件使用光华商场叫的到的货色，一天可以服务 1.2 Million 动态网页。对 Ruby on Rails 的高覆载度有问题吗，这篇文章可以打破你的疑惑。

7. Hemidemi：我所知道国内第一个 Ruby on Rails 网站，站长是我学长 XD，这一两个月成长开始爆发。

8. JaveEye：我最常举的例子，根据通过JavaEye2.0网站看ruby on rails性能这篇的说法，JavaEye 只用到一台光华商场买的到的机器，也就是 Web Server ，DB Server ，Mail Server ，Search Server 都在同一台。纯 Open Source 的架构，一天处理个 50 万应该没问题。

如果这些网站，还无法堵住『如果你打算用 Rails 给自己写个 Blog 或是小型的 Web 2.0 应用很合适』这样的嘴，那么我也没话说了。因为 Ruby on Rails 很年轻，所以用 Ruby on Rails 开发的站台大多营运时间只有一年不到，一个新兴网站其实有上面那么多流量其实已经很吓人了。如果再过个一年，或许会有流量更惊人的 Ruby on Rails 网站出现。

最后，当网站负载度到达一定程度，任何语言都不能可能承担这样的流量，所以网站的负载度还是看彼此的架构好坏，不是取决于语言本身，绝对没有一个站台只靠 PHP 或是 CGI 就可处理所有Request 的。语言或是框架对于乘载度的差别在于『转换高流量负载架构的弹性』，这点 Ruby on Rails 作的真的不差。

PS. Measure Map 是用 Ruby on Rails 写的，已经被 Google 买下来。

=====

blabla，但是我还有一个疑问，Ruby的线程问题如何解释他能够支撑大负载呢？难道真的要靠多进程吗？

“JavaEye 有一篇文章 Ruby的伪线程，讲述的是 Ruby 在 Thread 的问题。当然 Thread 对于 Performance 对于效能的进步是有很大的帮助啦。不过目前 Ruby 上面最有希望的 Native Thread Virtual Machine ：YARV 目前处于缓步状态。
”

根据 Another Year, Another Interpreter 这篇文章，更是抛下一个震撼弹

And then Matz and Koichi dropped the bomb: Ruby 2.0 would support neither continuations nor green threads.

真是太惨了，看来 Thread 在 Ruby 还是遥遥无期。这时候，Ruby 社群应该把重心投入在 YARV 上面，还是刚刚传出大捷报的 JRuby 上面呢？毕竟 JRuby 是 Native Thread 的，目标也是可以在 JVM 上面跑 Ruby on Rails （目前 JRuby 确定可以跑 Active Record ）。这似乎是一个好选择，不过 Ruby 社群是不是愿意将所有筹码压宝在 JRuby 呢？JRuby 现在可是由SUN 这家商业公司所主导的。

当然就算 Ruby 支持 Thread ，也会有很多问题要解决。Rails 本身不是 Thread Safe 的，Zed Shaw （Mongrel 作者）也说 Meta Programming 有很多 Thread Safe Probelm 。总之，Thread on Ruby 是一个难题，短期内也应该不会有很好的解法。