Grails vs Rails Benchmark

http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark

这个测试还是比较客观的。测试从以下几个方面进行：
   1.  Read operations
   2. Create operations
   3. Queries
   4. Update operations
   5. View rendering vs. writing directly to the response

总的来说Grails的速度好过Rails.

Graeme Rocher 根据Rails的建议部署了10个mongrel和Grails进行性能测试。结果还是一样Grails快过 Rails。

注：Graeme Rocher 是 Grails的创建者。

I updated the benchmark and configured Rails with 10 Mongrels and Pound as a load balancer as per Jared's blog. I also re-did the Grails tests with a tomcat maxThreads of 10 and the results were the Grails performed better and Rails performed worse:

docs.codehaus.org/display/GRAILS/Grails+vs+Rail...

Again, I appeal to the Rails community to suggest optimisation and improvements to the config of Rails. I will try out John's (above) suggestion of using nginx instead of Pound as a load balancer

C的速度不用测试都比Java快，那为什么不用C写web应用？

对于web应用来说，系统瓶颈就是数据库访问，特别是当数据量到十几万以后，这个时候你就是用汇编来写，页面访问速度也没有区别。所以测试JSP/ASP/PHP/Ruby的纯解析器性能，对于web应用，特别是OLTP应用来说，没有任何意义。

robbin,照你的意思在数据量到十几万以后Grails访问数据库不行？要知道GRAILS后面可是Hibernate. 另外适当的时候也可以用memcached(有JAVA客户端）来缓解Grails程序访问数据库的压力。

我没说Hibernate不行，我只说做web开发的框架，不测试数据库访问的功能和性能，等于没测。

Robbin你没有仔细看这篇测试报告，他是测试数据库的访问的。
ROR和Grails的测试性能差这么多，感觉是那个Notebook内存是瓶颈：开了10个芒果比1个竟然差。
偶已经写了一份信给他，问他有没有时间用2G的内存重新做一次，最好可以给出CPU/Memory在测试期间的profile。

首先我个人对这样的性能测试一直持否定态度，到不是因为我对RoR和Grails有什么感情色彩。而是这种测试根本就没有实际意义。

就拿JavaEye网站来说吧，在刚上线的时候，通过production.log的统计，可以清楚的知道每个页面请求，ruby执行时间在100ms到500ms之间。如果换成用Java开发，使用Hibernate/Spring/Webwork，根据我的经验表明，每个页面请求，Java执行时间大概在20ms到200ms之间。也就是说Java开发的web应用速度至少比RoR快3-5倍左右。这个不用做任何测试，都可以得出的结论。

但是这个结论没有任何实际意义！因为这种结论是在数据库数据量很小的情况下得出的。

现在JavaEye的数据库主要的表数据当膨胀到十几万几十万以后，复杂的关联查询耗时非常厉害，就是大表的简单count操作也耗时明显。所以一个页面请求平均需要500ms到2秒的执行时间，其中数据库查询占了绝大部分。这种情况下，就算换了Java。是的，我知道Java比RoR快3-5倍，但是一个页面请求照样需要500ms到2秒，因为Java再快也没有用，时间都消耗在大表的查询上了。

结论：web应用性能好坏不取决于你采用框架的性能，而取决于你的代码对数据库访问的优化能力

考察web应用性能，主要看你的代码对于数据库查询的优化，对于缓存的运用，以及框架对于缓存的支持能力。在框架的缓存支持能力上，Hibernate的对象缓存比AR的对象缓存强很多，这也是Hibernate的主要特色，RoR没有内置的对象缓存，外置的CachedModel只能提供简单的对象缓存，没有关联集合缓存，对象缓存是ORM强有力的性能武器，所以可以粗略的认为RoR的数据库访问性能不如Hibernate。但是Webwork或者其他任何Java Web框架没有提供页面缓存和片断缓存机制，而这方面是RoR的强项，像片断缓存就很适合类似博客个人页面这种场景。

PHP执行性能远不如Java，缓存能力更加不值得一提，但大型互联网站使用PHP的很多，可见对于web应用来说，框架本身的性能从来都不是一个值得考虑的问题。

这个测试就算能够得出Grails速度是RoR的10倍，也没有实际意义，但是测试本身还是能挑出很多问题来。

一、内存问题
readonly已经提到了，开10个mongrel，1G内存肯定不够用。

二、ab测试
如果用ab来测JavaEye，按照作者测试脚本，开到50个并发，JavaEye网站已经不能处理任何对外访问请求了。你一定可以得出结论，JavaEye性能很差。但实际上JavaEye现在每天处理超过30万动态请求，性能还不算差。

用ab来压，其压力远远超过实际应用场景，还是以JavaEye为例，真实用户访问的时候，web server的并发连接一般不会超过150个，在这150个并发连接当中，大部分是web server处理静态资源，连接HTTP连接，握手，断开等等协议通讯上，真正由web server转发给ruby FCGI进程处理的请求数量，一般不会超过10个，负载很高的情况下，也很少超过20个。

这个现象可能和大家的认知有比较大的出入，但这是事实。在真实应用场景中，如果服务器能够很好的支撑10个mongrel运行，那么每天支撑50万动态PV是没有任何问题的。但是在简单的ab 50个并发动态请求下，服务器基本不能响应更多的动态请求了。

三、部署方式
其实第二个问题还没有解释清楚，为什么ruby只需要10个进程就可以支撑50万动态PV。而tomcat要是只开10个线程肯定不够。因为部署方式不同。

对于ruby来说，前端一定要有web server，例如lighttpd/apache，所有的远程协议开销，静态资源处理，网络延时都被web server负担了，即使同时有100个用户在访问JavaEye网站，但是通过web server，到达ruby FCGI的动态请求在先后次序上就有差别了，1个FCGI进程在0.2秒时间处理完一个动态请求之后，再处理下一个动态请求，但是第一个请求通过网络延时达到用户浏览器端的时候，可能需要1-2秒钟。在这1-2秒时间内，一个FCGI进程可能已经处理了10个动态请求了。所以即使100个并发用户，实际上也只需要10个FCGI进程。

tomcat如果在前端不放置web server，那么100个用户并发，tomcat就得启动100个线程，当然大部分线程都被浪费在静态资源处理，协议通讯和网络延时上了，真正处于繁忙的动态请求的并发线程也不会超过10个。

ab测试抹杀了真正应用中的网络延时和静态资源处理负载，而作者的部署方式中RoR根本没有放前端web server。



说了这么多废话，那要做真正的性能测试应该怎么测？

1、被测web应用本身要复杂一些，具备典型的web应用场景
2、数据库数据量起码要上千，不能把空数据库拿出来测试
3、使用专门的测试服务器，被测系统和测试脚本在一起跑，不可能准确
4、测试服务器CPU需要两路，内存至少2GB，能够4GB是最好的
5、RoR的部署方式采用lighttpd+fcgi，开10个fcgi进程
6、Grails的部署方式采用apache2.2+tomcat5.5，tomcat使用APR调度线程
7、使用loadrunner录制典型的用例脚本
8、通过loadrunner定制，模拟并发用户处理不同的业务逻辑操作

然后看loadrunner的测试结果。

测试二：

1、在测试一基础上给Grails的Hibernate添加二级缓存配置
2、在测试一基础上给RoR添加CachedModel，Memcached，以及其他可能的片断缓存

再次运行loadrunner测试脚本，看测试结果。

实践出真知,学习le