2006-10-09
通过JavaEye2.0网站看ruby on rails性能
关键字: rails performance
ruby on rails作为web开发框架,通常被认为性能很差,并因此被置疑其前景。JavaEye2.0网站使用ruby on rails开发,已经上线运行一个月了,通过这一个月的运行,我们可以对ruby on rails的性能有一个初步的认识。
JavaEye2.0运行的服务器硬件配置:
这是一个标准的低端1U机架式服务器,大概能够以15k价格购买到,可以说是相当便宜的硬件配置了。
JavaEye2.0的软件运行环境:
此外服务器上面还运行了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在性能方面并不会成为一个问题。
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在性能方面并不会成为一个问题。
评论
dearsuper
2007-09-04
robbin,实践者。是那些真正的实践者,在影响世界。
strongkill
2007-09-04
小弟的网站也是用lighttpd+ruby做的.http://www.strongd.net
感觉比PHP+APACHE好很多.
感觉比PHP+APACHE好很多.
jimxl
2007-09-01
kris_xu 写道
当今硬件应该不是效率的瓶颈了吧。这么精确的计算能够说服企业用ruby?
现在有支持ruby的空间么?
现在有支持ruby的空间么?
现在这样的空间太多了.
gigix
2007-09-01
kris_xu 写道
当今硬件应该不是效率的瓶颈了吧。这么精确的计算能够说服企业用ruby?
现在有支持ruby的空间么?
现在有支持ruby的空间么?
企业应用不会用共享空间的
uu4u
2007-09-01
呵呵,今天才看到,有点相见恨晚的感觉,其实,从年初就开始学习RoR,但是,一直仅限于Demo似的的开发学习,没有真正的做过项目,而且是三天打鱼,两天晒网的。看来,还要好好学习学习的。
深蓝_
2007-05-21
Ruby On Rails和 Grails 性能相比呢??
kris_xu
2007-05-17
当今硬件应该不是效率的瓶颈了吧。这么精确的计算能够说服企业用ruby?
现在有支持ruby的空间么?
现在有支持ruby的空间么?
bruce.lu
2007-05-17
good article, thanks, hoping 4 more ones like this...
basicbest
2007-02-09
从实际情况来看,性能还是很不错的。
Robbin有没有兴趣实际做一下压力测试?
我很想知道,每秒10 20 50 100个并发请求下的实际表现。
Robbin有没有兴趣实际做一下压力测试?
我很想知道,每秒10 20 50 100个并发请求下的实际表现。
nwangwei
2007-02-08
[quote="robbin"]
JavaEye2.0的软件运行环境:
[quote]Linux Kernel-2.6.7,lighttpd-1.4.13,MySQL-5.0,ruby-1.8.4(GC patch)[/quote]
......
服务器的平均CPU使用率在繁忙的时候,大概15%左右,MySQL数据库繁忙的时候平均每秒发送超过100条SQL语句,24小时平均每秒发送45条SQL语句。硬盘IO非常少,每秒读硬盘非常低,每秒写硬盘平均200KB左右(操作系统进行了充分的disk cache,MySQL Cache使用率也几乎满了)。
[/quote]
[/quote]
我比较关心数据库,问一下您使用的是 MySQL 的什么数据库格式呢,最大的表格有多少的数据量呢?
一般 SQL 语句中select、insert和update的比率大概是多少呢?
感觉 Web 应用确实在数据库上花费时间很多哎~
JavaEye2.0的软件运行环境:
[quote]Linux Kernel-2.6.7,lighttpd-1.4.13,MySQL-5.0,ruby-1.8.4(GC patch)[/quote]
......
服务器的平均CPU使用率在繁忙的时候,大概15%左右,MySQL数据库繁忙的时候平均每秒发送超过100条SQL语句,24小时平均每秒发送45条SQL语句。硬盘IO非常少,每秒读硬盘非常低,每秒写硬盘平均200KB左右(操作系统进行了充分的disk cache,MySQL Cache使用率也几乎满了)。
[/quote]
[/quote]
我比较关心数据库,问一下您使用的是 MySQL 的什么数据库格式呢,最大的表格有多少的数据量呢?
一般 SQL 语句中select、insert和update的比率大概是多少呢?
感觉 Web 应用确实在数据库上花费时间很多哎~
thegiive
2007-02-06
Physon 写道
比 PHP 不是慢一点哦. 不过也是, 能满足需求就好, 而且还有很多非语言级别的措施. 但是, 别忽略了, 如果 PHP 或是 Java 也来一个轻量级的框架呢? 因此, 要想挤进企业级应用, Ruby 本身任重而道远.
PHP 的確比 Ruby 快,不過 PHP 的框架跟 Ruby 的框架校能比呢?
這個 benchmark 剛好做出相反地結果
http://lightyror.thegiive.net/2007/01/rubypythonperlphp.html
語言的快慢是一回事,用效能比較快的語言並不代表這個語言的框架會比較快
還是一句話「當語言的效能差距不大時,框架設計者他們的實做的功力分高下」
robbin
2007-02-03
Physon 写道
比 PHP 不是慢一点哦. 不过也是, 能满足需求就好, 而且还有很多非语言级别的措施. 但是, 别忽略了, 如果 PHP 或是 Java 也来一个轻量级的框架呢? 因此, 要想挤进企业级应用, Ruby 本身任重而道远.
和PHP是两码事。Java还比C慢不是一点呢。
Physon
2007-01-31
比 PHP 不是慢一点哦. 不过也是, 能满足需求就好, 而且还有很多非语言级别的措施. 但是, 别忽略了, 如果 PHP 或是 Java 也来一个轻量级的框架呢? 因此, 要想挤进企业级应用, Ruby 本身任重而道远.
robbin
2007-01-29
gKarerM 写道
请教robbin一个问题,每秒钟发送的SQL数量和磁盘IO怎么查看?这方面我完全文盲
mytop, iostat
gKarerM
2007-01-29
请教robbin一个问题,每秒钟发送的SQL数量和磁盘IO怎么查看?这方面我完全文盲
strongkill
2007-01-16
不能只看单单数据来定出某种语言/框架的性能.要长时间,大家一齐用实践来证明的.
robbin
2006-10-14
Lucas Lee 写道
而且我想问问robbin,是不是你们的论坛没有对帖子等数据作缓存?每次访问都是到数据库里查一次?Jive论坛程序据说有大量的缓存,所以性能会很高,不知道以前这里用的PHPBB是不是也没有缓存帖子。
如果没有缓存,有这样的性能,倒还是不错的。搞缓存还是比较麻烦,能用硬件对付过去,还是节省点开发成本的好。
如果没有缓存,有这样的性能,倒还是不错的。搞缓存还是比较麻烦,能用硬件对付过去,还是节省点开发成本的好。
还没有使用任何缓存,每次动态请求都是访问数据库。
Lucas Lee
2006-10-13
而且我想问问robbin,是不是你们的论坛没有对帖子等数据作缓存?每次访问都是到数据库里查一次?Jive论坛程序据说有大量的缓存,所以性能会很高,不知道以前这里用的PHPBB是不是也没有缓存帖子。
如果没有缓存,有这样的性能,倒还是不错的。搞缓存还是比较麻烦,能用硬件对付过去,还是节省点开发成本的好。
如果没有缓存,有这样的性能,倒还是不错的。搞缓存还是比较麻烦,能用硬件对付过去,还是节省点开发成本的好。
Lucas Lee
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的数据库应用一般来说性能瓶颈都是数据库的话,那就有意义了。
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应用因素很多的,往往最终性能的瓶颈都是数据库。
- 浏览: 1677846 次
- 性别:

- 来自: 上海

- 详细资料
搜索本博客
我的相册
游乌镇
共 33 张
共 33 张
链接
最新评论
-
mod_rails尝鲜
我觉得还是mod_fcgid(不是mod_fastcgi)实际点
-- by zgd -
mod_rails尝鲜
hostingrails也已经提供mod_rails了
-- by leondu -
mod_rails尝鲜
dreamhost已经提供mod_rails了
-- by zgd -
关于JavaEye网站未来发展 ...
期待第三阶段目标的实现,但第三目标好像类似于google的云计算,建议赶紧开发, ...
-- by selectme_2008 -
总结一下大家对JavaEye网 ...
javaeye是我比较喜欢的一个网站,但盈利模式还是比较单一,让人怀疑网站是否能 ...
-- by selectme_2008






评论排行榜