关于Rails Scaling的系列文章

我的意思是J2EE模型和这种http代理模型都能scale，当达到一定的程度，这两者的区别可能并不是很大

至于硬件设备的投资，应该说是不大的，关键在于开发的速度和维护、升级、用户需求响应的能力，当然还有程序员的happy.举个简单的例子，公司每个月的费用是30W，那么产品早出来一个月，节约的成本就是30W，这个成本不能单单算开发人员的工资。更不用说机会成本了。

所以，不管J2EE还是ROR，最后都需要把精力放在这上面。

7台机器才顶住每天120万也好意思拿出来说

http://bbs.sjtu.edu.cn

1台AMD64位服务器，4G的内存，每天140万以上Request，毫无问题。跑的是lighttpd+fcgi+C，没有数据库

开发速度乃是RoR的已知优势所在，而不同规模下的scaling成本现在还在考察和试验中，这篇文章描述的应该就是其中的一个例子。我认为，其目的不是想说明“RoR比现在的技术更快、更节约资源”，而是意图传达“RoR也还是可以将‘延展性’控制到比较好的程度”这个意思。简单的说就是想为已经或者想要运用RoR的人消除疑虑，也帮community打下气。

P.s. 国内一般都是等技术“成熟了”，才拿过来用（很大程度上就是搬别人试验好了的模式和方法）；其实这次RoR的兴起也许又是一个从一开始就参与技术发展的机会……

本人才疏学浅，入行也不长，说得不对还请见谅。

诸位，性能和应用的复杂性、可扩展性、动态性、开发成本有相互的权衡关系的。世界上没有绝对的事情。


况且主题是进程proxy模型（fcgi/scgi/mongrel)的伸缩性问题。

楼上的也说明了这种fcgi的模型在单台机器上也是可以达到很高性能的

我非常赞同这种看问题的方式

恩。。。的确应该从这个角度去理解那篇文章。。。

bbs是专用系统, 不是通用开发平台. 其次firebird bbs开发历史已经有十几年了, 为资源利用和性能做了大量的优化.

其实firebird bbs本身的效率并不高，而且BUG还不少。但是基于firebird之上有许多性能优化后的版本，都是各个系统使用者针对自己的具体情况优化的。国内公认的优化的最好的是水木清华和被强制关闭的ytht。不过我这里说的不是telnet的firebird，而是web下的BBS，跟firebird没多大关系。

没有数据库跟有数据库的性能要求要差一个数量级呢。

根本没有可比性啊。

没有数据库的话，关系处理就不容易做了。
企业应用不仅仅是浏览，还要分类，计算，联合计算……

不过用文件系统做bbs是适合的, 都是文本来文本去, 省掉很多负担. 只是这过于专用, 一般项目也没时间和足够人力用c去做.