通过JavaEye2.0网站看ruby on rails性能

ruby on rails作为web开发框架，通常被认为性能很差，并因此被置疑其前景。JavaEye2.0网站使用ruby on rails开发，已经上线运行一个月了，通过这一个月的运行，我们可以对ruby on rails的性能有一个初步的认识。

JavaEye2.0运行的服务器硬件配置：

引用

HP DL145 G1，两路AMD Operton 2GHz CPU， 4G DDR RAM， 73G SCSI 15k Disk

这是一个标准的低端1U机架式服务器，大概能够以15k价格购买到，可以说是相当便宜的硬件配置了。

JavaEye2.0的软件运行环境：

引用

Linux Kernel-2.6.7，lighttpd-1.4.13，MySQL-5.0，ruby-1.8.4(GC patch)

此外服务器上面还运行了Email Server，Tomcat等服务

在JavaEye2.0刚刚上线的时候，启动了50个FastCGI ruby进程，发现大量空闲FastCGI进程，随后根据运行情况，不断减少进程数量，目前只启动了20个FastCGI进程，因此负载量还是很轻的。

服务器的平均CPU使用率在繁忙的时候，大概15%左右，MySQL数据库繁忙的时候平均每秒发送超过100条SQL语句，24小时平均每秒发送45条SQL语句。硬盘IO非常少，每秒读硬盘非常低，每秒写硬盘平均200KB左右(操作系统进行了充分的disk cache，MySQL Cache使用率也几乎满了)。

通过上面这些服务器运行情况，可以大致得出一个结论，目前JavaEye2.0网站在这种低端硬件上面的负载量非常轻，对硬件消耗不大。

目前JavaEye2.0网站使用了Google Analytics来统计网站的访问量。根据这一个月的统计量，周一到周五一般每天动态网页PageView超过5万，周六周日和国庆期间每天动态网页PageView超过2万。但是根据对rails的production.log进行统计，24小时，rails正常处理的、状态为200 OK的Action动态请求数量有12万多。也就是说网站每天正常处理动态请求超过了12万。

由于网站的访问量大部分集中在早上9.00到晚上9.00这12个小时的范围内。因此可以大致粗略的认为12小时处理12万动态请求，平均每小时处理1万动态请求，也就是说平均每秒处理3个动态请求。

观察production..0X秒，少量请求是0.X秒，如果我们按照平均每个请求处理时间为0.1秒计算，那么一个FastCGI进程每秒可以处理10个请求，从目前JavaEye2.0网站的运行状况来看，支撑每天60万动态请求，看来是毫无问题的。所有的这些还是没有对程序进行必要的Cache优化所取得的，如果对程序进行充分的优化，达到每天支撑100万动态请求也是可以做到的。

如果一个网站能够到达每天50万动态请求，已经是一个相当大的网站了，对于那些企业应用来说，访问量也往往达不到这么大的流量，因此从JavaEye2.0网站的运行情况来看，ruby on rails在性能方面并不会成为一个问题。

评论

15 楼 LucasLee 2006-10-13  

而且我想问问robbin，是不是你们的论坛没有对帖子等数据作缓存？每次访问都是到数据库里查一次？Jive论坛程序据说有大量的缓存，所以性能会很高，不知道以前这里用的PHPBB是不是也没有缓存帖子。

如果没有缓存，有这样的性能，倒还是不错的。搞缓存还是比较麻烦，能用硬件对付过去，还是节省点开发成本的好。

14 楼 LucasLee 2006-10-13  

robbin 写道

单纯比较JVM，PHP解析器，ruby解析器的话，肯定是JVM最快，ruby解析器最慢，这个结论是很明确的事情了。

但是对于一个具体环境部署的web应用来说，这个web应用体现出来的吞吐量，负载能力，是取决于很多因素的，解析器的性能只是其中一个因素而已。而且通过一系列实践来看，ruby解析器的低性能对于整体web应用性能的影响并不明显。

因此ruby解析器虽然性能差，但是ruby on rails开发的web应用性能却并没有表现得差，甚至还挺不错的，这个就是我想说明的。

至于非要和PHP和Java比较，其实意义不大，因为影响web应用因素很多的，往往最终性能的瓶颈都是数据库。

懂你的意思了。

我有个想法，有点远了，如果你能给出这个论坛的性能参数在数据库处理和Ruby处理之间的比率，我想更有意义，可以借鉴到其他数据库类的程序。我不是很懂性能参数，这个参数似乎应该是cpu占用率与时间的乘积，一个微积分的面积问题，然后把数据库的这个值和Ruby处理的值作一个比率。不知道是不是有现成工具可以测得出。

如果你的想法被证明成立，即web的数据库应用一般来说性能瓶颈都是数据库的话，那就有意义了。

13 楼 robbin 2006-10-13  

Lucas Lee 写道

robbin 写道

Lucas Lee 写道

听上去的确还不错。不过我想问robbin的是，同样的网站，ROR做的还是会比PHP的慢吧？否则你也不用自己买服务器了？

我自己买服务器是因为原来的服务器运行环境太不稳定了。

我没有做过实际案例的对比测试，不清楚同样一个web应用，究竟哪个稍微快点。不过我根本就不关心这一点，谁快点慢点根本就无关紧要。

但其实这一点还是有相当的感性认识作用的。比如有些人比较了解PHP或ASP或JSP论坛的负载能力，给出一个大概的比较，还是很有说服力的。光说一些指标会显得空泛了。
比如说Oracle新版本，什么配置能达到多少TPS，对于很多人来说，那只是一个数字，很可能没有任何感觉；如果给出新版本对旧版本的大概百分比，会有效得多，当然只是一个概述，细节可能有很多变化。

单纯比较JVM，PHP解析器，ruby解析器的话，肯定是JVM最快，ruby解析器最慢，这个结论是很明确的事情了。

但是对于一个具体环境部署的web应用来说，这个web应用体现出来的吞吐量，负载能力，是取决于很多因素的，解析器的性能只是其中一个因素而已。而且通过一系列实践来看，ruby解析器的低性能对于整体web应用性能的影响并不明显。

因此ruby解析器虽然性能差，但是ruby on rails开发的web应用性能却并没有表现得差，甚至还挺不错的，这个就是我想说明的。

至于非要和PHP和Java比较，其实意义不大，因为影响web应用因素很多的，往往最终性能的瓶颈都是数据库。

12 楼 LucasLee 2006-10-13  

robbin 写道

Lucas Lee 写道

听上去的确还不错。不过我想问robbin的是，同样的网站，ROR做的还是会比PHP的慢吧？否则你也不用自己买服务器了？

我自己买服务器是因为原来的服务器运行环境太不稳定了。

我没有做过实际案例的对比测试，不清楚同样一个web应用，究竟哪个稍微快点。不过我根本就不关心这一点，谁快点慢点根本就无关紧要。

但其实这一点还是有相当的感性认识作用的。比如有些人比较了解PHP或ASP或JSP论坛的负载能力，给出一个大概的比较，还是很有说服力的。光说一些指标会显得空泛了。
比如说Oracle新版本，什么配置能达到多少TPS，对于很多人来说，那只是一个数字，很可能没有任何感觉；如果给出新版本对旧版本的大概百分比，会有效得多，当然只是一个概述，细节可能有很多变化。

这一点让我想起毕业论文答辩：我做的一个利用废料作原料的建筑玻璃工艺，导师就让我说什么什么情况下，一年能给工厂节约多少个百万，说领导就爱听这个；我当时自己就觉得有疑问，没有基数，这个百万似乎没有意义，自己算了个百分比；结果答辩时就用上了，有意思。

11 楼 zwhua 2006-10-13  

不错，好久没有来了，呵呵！

10 楼 raymond 2006-10-13  

很好，对于我继续学习Ruby有很积极的广告效应。 

9 楼 robbin 2006-10-12  

Lucas Lee 写道

听上去的确还不错。不过我想问robbin的是，同样的网站，ROR做的还是会比PHP的慢吧？否则你也不用自己买服务器了？

我自己买服务器是因为原来的服务器运行环境太不稳定了。

我没有做过实际案例的对比测试，不清楚同样一个web应用，究竟哪个稍微快点。不过我根本就不关心这一点，谁快点慢点根本就无关紧要。

8 楼 LucasLee 2006-10-12  

听上去的确还不错。不过我想问robbin的是，同样的网站，ROR做的还是会比PHP的慢吧？否则你也不用自己买服务器了？

7 楼 hijack 2006-10-11  

Uranus 写道

不错不错，没想到这个论坛是用ROR做的，不错，有时间研究下RUBY，不知道论坛代码能不能共享下,赫赫！

随便弄个错误信息就知道了。比如访问http://xx.iteye.com/

6 楼 Uranus 2006-10-11  

不错不错，没想到这个论坛是用ROR做的，不错，有时间研究下RUBY，不知道论坛代码能不能共享下,赫赫！

5 楼 kryptonum 2006-10-11  

从Robbin提供的数据来看，在目前的吞吐量下，RoR的性能相当不错
现在的问题就是当访问量大增的时候性能的曲线是什么样的

4 楼 thundercao 2006-10-10  

实践出真知

3 楼 cookoo 2006-10-10  

哈哈，记得以前robbin问我：如果一个请求处理要1秒，每个fastcgi进程有10个请求排队，那每个请求要等10秒了? 答：对阿。。。

2 楼 robbin 2006-10-09  

200个应该达不到。不过从目前硬件资源占用率来看，每秒达到30个以上是没有什么问题的。

1 楼 qiezi 2006-10-09  

robbin 写道

观察production.log，大部分动态请求处理时间都是0.0X秒，少量请求是0.X秒，如果我们按照平均每个请求处理时间为0.1秒计算，那么一个FastCGI进程每秒可以处理10个请求，总共20个FastCGI进程每秒处理200个请求，即每小时处理72万请求，每天至少可以处理700万动态请求，折算实际访问量，也应该至少有200万PageView了。

这个不能这样简单地计算吧，除非你有20个CPU，每进程只有1线程，那还得保证磁盘和其它资源没有成为瓶颈。每秒200个动态请求还是挺吓人的。