2008-06-04
Spring性能小测，参其它技术
关键字: spring
昨天参与了“有感而发：JavaEE和ROR的本质区别，以及对ROR的抱怨”（http://pig345.javaeye.com/blog/199384）博文上的口水战，对Quake Wang老兄所说的“Ruby比Java确实性能差很多，但是RoR和Struts + Spring + Hibernate做的网站性能是在同一级别的”产生了兴趣，今天抽空测了一下，发现了一些有趣的事情。
首先声明这些测试并不严格，全是在同一台机器（Core2 1.6，2G内存PC）上跑，DB是同一个MySQL，执行简单的单表读写操作，并发100个thread（此并发情况下各种技术基本都不会出Error），都不做缓存。数值都是取rps，具体的绝对数值没有考究的意义，不过相对一比较倒有些意思。
先用笔者前两三年一度热衷的Appfuse，测下来的结果大概在130左右；
然后直接采用Spring的三个例程，一来简单，二来Rod自制的Sample效率应当是有保证的，结果如下：
采用hibernate的petclinic：200左右；
采用ibatis的jpetstore：400左右；
采用jdbc的imagedb：750左右。
大家应该看出些门道来的吧。所以说Rod老大的确是聪明绝顶，早已预备了三种不同的性能方案，做成sample给大家采用。至于大家最后怎么用是自己的事，怪Spring就不对了，Rod真是高明！
顺便附上其它技术体系的参考值（由高到低）吧：
纯PHP：1000左右；
以快速闻名的FleaPHP：800左右；
JSTL：350左右；
Grails：50左右；
Seam：20左右；
RoR：12左右。
这下大家是不是有些总的概念了。基本规律是越偏向SQL的技术，性能越高；越偏向ORM的技术，性能越低。由此可见OO和关系DB的不匹配，不仅仅是在设计和编码上，在性能上更是个天大的问题。
差距如此之大，就连笔者也不禁怀疑起自己的测试。建议有心的同道们做一下更严格的测试以资验证。
值得一提的是，在引入DB前，JSP还是要快过PHP不少，大概是1900：1400左右，但加上DB后，JSP竟然干不过PHP，身为Java fans实在是有些愤怒。不过很久不写JSP了，但愿精于此道的同道写个更高效的，压过PHP才好。
现代主流DB在此配置下每秒钟大多能吞下500－1000条普通SQL。做为中间层，不管怎么做，还是要配得上才行。
是选择开发效率低一些，但性能高的偏SQL方案，还是选择开发效率高，但性能低的编OO方案，不同的场景有不同的回答。
但愿此文能帮助各位同道在不同的项目上能对性能－开发效率做出最好平衡的正确选择。
首先声明这些测试并不严格，全是在同一台机器（Core2 1.6，2G内存PC）上跑，DB是同一个MySQL，执行简单的单表读写操作，并发100个thread（此并发情况下各种技术基本都不会出Error），都不做缓存。数值都是取rps，具体的绝对数值没有考究的意义，不过相对一比较倒有些意思。
先用笔者前两三年一度热衷的Appfuse，测下来的结果大概在130左右；
然后直接采用Spring的三个例程，一来简单，二来Rod自制的Sample效率应当是有保证的，结果如下：
采用hibernate的petclinic：200左右；
采用ibatis的jpetstore：400左右；
采用jdbc的imagedb：750左右。
大家应该看出些门道来的吧。所以说Rod老大的确是聪明绝顶，早已预备了三种不同的性能方案，做成sample给大家采用。至于大家最后怎么用是自己的事，怪Spring就不对了，Rod真是高明！
顺便附上其它技术体系的参考值（由高到低）吧：
纯PHP：1000左右；
以快速闻名的FleaPHP：800左右；
JSTL：350左右；
Grails：50左右；
Seam：20左右；
RoR：12左右。
这下大家是不是有些总的概念了。基本规律是越偏向SQL的技术，性能越高；越偏向ORM的技术，性能越低。由此可见OO和关系DB的不匹配，不仅仅是在设计和编码上，在性能上更是个天大的问题。
差距如此之大，就连笔者也不禁怀疑起自己的测试。建议有心的同道们做一下更严格的测试以资验证。
值得一提的是，在引入DB前，JSP还是要快过PHP不少，大概是1900：1400左右，但加上DB后，JSP竟然干不过PHP，身为Java fans实在是有些愤怒。不过很久不写JSP了，但愿精于此道的同道写个更高效的，压过PHP才好。
现代主流DB在此配置下每秒钟大多能吞下500－1000条普通SQL。做为中间层，不管怎么做，还是要配得上才行。
是选择开发效率低一些，但性能高的偏SQL方案，还是选择开发效率高，但性能低的编OO方案，不同的场景有不同的回答。
但愿此文能帮助各位同道在不同的项目上能对性能－开发效率做出最好平衡的正确选择。
评论
有问题的是用hibernate的人
hibernate没问题 是说它在任何情况下都没问题，都适用呢，还是说超过一个百分比的情况没问题。
请问这个百分比是多少。
如果将这类问题老是搞得看不见的话，就会有人不断提这种问题。
编辑们多努力阿。
题外话说完了，说和性能相关的问题。
其实最能改善软件性能的是大脑的性能，robbin已经说得如此明白，但是有的同学仍然固执到坚强的地步，不知道是不明白，还是放不下。
大的架构方面的robbin已经说了。我从中学到不少。
既然说语言，那就说说语言，不管是C++，Java，ruby，写得好不好对性能的影响远远超过了语言本身。
以前曾经有几个Oracle存储过程，用来计算一些报表数据。计算一次需要20小时左右。
一再给客户解释，存储过程性能问题，要解决要用C语言重写。我最讨厌的就是将时间花在为自己无能的辩解上，而不是花在解决问题上。结果，我将存储过程改写后，四个小时就可以计算完成。发现任何错误重新计算正确的时间在5分钟以内。
不要解决假想的问题，不要把时间浪费在讨论哪门语言上，碰到问题是个好机会，解决它。不要怀疑你所用的语言，多怀疑自己。
做一个小程序来测试性能是很搞笑的事情。
经常见到不到100万条数据就在那里叫数据好多。
搞个连玩具都算不上的东东在那里比较性能。
真的，比较性能这种事，你目前还没有必要做。要做的事，尽可能提高现有系统的性能。重构代码，优化服务器。
上面有位同学说导出20W条数据够呛，其实十几分钟不算长，如果一个月导一次，有什么关系？但内存溢出问题不得不解决。
如果一天导个几次，或者有一万个人要导，而不仅仅是办公室主任一个人要，就是大问题了。任何问题离开了实际的场景没有任何意义。
导这20W数据还有机器配置的问题。
做一件事情，最重要的是方法问题。
让我猜一下这个问题吧。
首先要确认是计算花时间，还是写Excel花时间。
是否可以建临时表，临时文件
是否可以使用多线程
只要把问题搞清楚了，就好解决。
我做过，处理上千万数据生成N个报表，也不需要这么长时间。用的是C++。
但我相信不是语言的问题。
现在一般的PC都比那时好，所以应该更快。
作为程序员，请不要写令人发指的程序来冤枉编程语言。
java有个缺点就是对象的回收速度上比不上C++
一般的计算不花时间,尤其表不是巨大的时候,20w的数据显得不是特别大,excel的cell创建和style渲染会耗费大量的cpu,否则分页输出web格式的报表还是没有太大的问题的,不像excel输出如此变态.
2。上面谁说ORM,jdbc，在说什么orm快，jdbc快,我只知道两个要点 一：我知道orm都是在jdbc上的,二，程序都是耗时间的
第一点有问题：jdbc不带cache。
可以自己加cache，也不是什么麻烦事。
是啊，不麻烦，jdbc+自己的cache再加上通过反射读取原数据定义（或者xml定义），动态生成sql，就是hibernate了。
我就是把Hibernate当成sql生成器起来用的，从来不把它当什么面向对象数据接口，绝对比什么iBatis方便，特殊需求除外（创建表等）。
还有就是Hibernate对原生sql的支持度是很强的，很多人刚入门的不知道而已，只知道个iBatis。
使用iBatis，一旦碰到sql是要根据一些复杂业务的条件拼出来的就知道痛苦了，大量的工作量在写配置文件和配置脚本，IDE对配置文件支持度是远不如代码的。
2。上面谁说ORM,jdbc，在说什么orm快，jdbc快,我只知道两个要点 一：我知道orm都是在jdbc上的,二，程序都是耗时间的
第一点有问题：jdbc不带cache。
可以自己加cache，也不是什么麻烦事。
2。上面谁说ORM,jdbc，在说什么orm快，jdbc快,我只知道两个要点 一：我知道orm都是在jdbc上的,二，程序都是耗时间的
第一点有问题：jdbc不带cache。
如果将这类问题老是搞得看不见的话，就会有人不断提这种问题。
编辑们多努力阿。
题外话说完了，说和性能相关的问题。
其实最能改善软件性能的是大脑的性能，robbin已经说得如此明白，但是有的同学仍然固执到坚强的地步，不知道是不明白，还是放不下。
大的架构方面的robbin已经说了。我从中学到不少。
既然说语言，那就说说语言，不管是C++，Java，ruby，写得好不好对性能的影响远远超过了语言本身。
以前曾经有几个Oracle存储过程，用来计算一些报表数据。计算一次需要20小时左右。
一再给客户解释，存储过程性能问题，要解决要用C语言重写。我最讨厌的就是将时间花在为自己无能的辩解上，而不是花在解决问题上。结果，我将存储过程改写后，四个小时就可以计算完成。发现任何错误重新计算正确的时间在5分钟以内。
不要解决假想的问题，不要把时间浪费在讨论哪门语言上，碰到问题是个好机会，解决它。不要怀疑你所用的语言，多怀疑自己。
做一个小程序来测试性能是很搞笑的事情。
经常见到不到100万条数据就在那里叫数据好多。
搞个连玩具都算不上的东东在那里比较性能。
真的，比较性能这种事，你目前还没有必要做。要做的事，尽可能提高现有系统的性能。重构代码，优化服务器。
上面有位同学说导出20W条数据够呛，其实十几分钟不算长，如果一个月导一次，有什么关系？但内存溢出问题不得不解决。
如果一天导个几次，或者有一万个人要导，而不仅仅是办公室主任一个人要，就是大问题了。任何问题离开了实际的场景没有任何意义。
导这20W数据还有机器配置的问题。
做一件事情，最重要的是方法问题。
让我猜一下这个问题吧。
首先要确认是计算花时间，还是写Excel花时间。
是否可以建临时表，临时文件
是否可以使用多线程
只要把问题搞清楚了，就好解决。
我做过，处理上千万数据生成N个报表，也不需要这么长时间。用的是C++。
但我相信不是语言的问题。
现在一般的PC都比那时好，所以应该更快。
作为程序员，请不要写令人发指的程序来冤枉编程语言。
1，google用python是做什么？粘合剂？太模糊了吧，google用c++作为主力是真的，要求性能的分布式系统都是c++写的，而python是他们的管理系统，至于java是用来干什么的，我不知道，不过我知道他们有40%左右的java开发人员，当然这些人也非常擅长于c++以及python，甚至很多还是js高手，我是说他们一些部门的开发人员。比如mountain view的很多是混混。
2，至于java php ruby性能比拼！我觉得我们不是在写火星车导航系统，计算慢一点没关系的。同时也不是在写apache火力控制系统，稳定性也不用考虑。我们只是在做web app，所以我们看中的不是谁跑的快，而是用那种语言来做，容易跑的快，这个差别很大的。毕竟计算1+2+3。。。+100很快，不代表写一百个模块的系统也很快，反之亦然。
3，ebay里面没听说有牛人，估计只好请咨询啦，看java的要看walmart的，毕竟terracotta的老大来自哪里
之前听说过google用Tapestry，不过找不到明确证据，要说google用java做web的侧面证据是GWT是java的。
这种时候，用什么语言都一样，所以我基本同意robbin的观点的。
小声地问一下,你不分开几个文件导出么?20w分10次,导到temp中10个文件,然后合并输出不可以?
有问题的是用hibernate的人
这种时候，用什么语言都一样，所以我基本同意robbin的观点的。
上面我已经说过了，没什么服气不服务的问题，因为哪个快一些，哪个慢一些根本就无关紧要。其实我可以做这样的测试，而且事实上我经常私下做各种性能测试，考察不同框架的性能和伸缩性表现。但是测试不同编程语言不同框架速度快一点还是慢一点，这个根本就是没有意义的事情，而且你所谓的感性认识还是个错误的认识，很可能导致你在将来的技术选型和框架设计上做出错误的决定。
我这里也做一做测试，不管是好是赖，放上来让大家讨论一下。顺便鼓励大家都去做一做，好好考量一下自己系统的性能，至于有没有意义大家自己去判定。
如果照你的说法，这种性能测试是根本没有意义的。是不是说现在凡是可以做B/S的，语言和框架快慢是无所谓的事情，也就是说根本不用去选了。既然性能最后都大同小异了，是不是说开发效率才是唯一的标尺。
如此这般的结论，那就还是选择当前开发效率高的RoR了。
可惜，本人在现实工作中，不论是自己开发还是其它厂商的东西，在存储过程、SQL和ORM之间还是有差距的；而众所周知的Spring和EJB之间，也还是有差距的。
比如让RoR做一下库存盘点，医保结算，代码写起来是够清晰的，可惜那个速度......。换存储过程和SQL看看，还说是没有差距吗？
不要觉着是在找碴。企业应用中，尤其是大家这些年看不上眼，以为是过时的SQL+C/S系统里面，这类复杂的业务逻辑太多了。想要改朝换代，先过性能这一关。
无意义的讨论很容易误导其它人的，既然robbin指出你的测试方式有问题，测试出来的数据没有任何意义。那为什么不询问下有意义的测试方式，最后得到一些有意义的数据呢。我遇到的企业项目的开发中，最后出性能问题基本上都是设计上的失误，很少有因为语言性能导致的。
另外如果是想证明ORM的效率低下，影响应用的性能的话，那么就要考虑你为什么要用ORM了，还不是为了程序结构好些，开发简单些。
不过我个人认为：robbin的观点还是占上风的。
1。我不明白为什么CPU占100%
2。上面谁说ORM,jdbc，在说什么orm快，jdbc快,我只知道两个要点 一：我知道orm都是在jdbc上的,二，程序都是耗时间的
1、100个thread不停地冲WebServer10分钟，当然是CPU占用率100%了。这种极端测试，主要是看在这种崩溃边缘，谁还能反应正常一些。结果是Spring jdbc和纯JSP、PHP。
2、两点之间直线最短，绕了几个弯弯还想快，问问机器再说。
这种极端测试，大家也不要觉得是撑饱了没事儿干。现实当中就有大量这种平时懒散，高峰时段并发高得吓人的负载。比如大型医院每天上午的9:00-12:00，医保中心的月底结算、物流企业的盘点等等。不搞定这些要求，少不了是要被Oracle DBA数落嘲笑的。那些时候，恨不得榨干机器的最后一滴油。
当初天下闻名的奥运票务事件，如果当初多做做这种极端测试，也许就不至于放出那么不切实际的承诺，贻笑大众了。
Java快，但是没C快，难道你用C做web？所以大公司里的构架都是乱啊，老大都不管这些小问题，他们只考虑如何度过每一天。martin flower喜欢玩些花样，我听说ari就不喜欢martin的想法
我们只是在做web app，所以我们看中的不是谁跑的快，而是用那种语言来做，容易跑的快，这个差别很大的。
终于遇到个知音，这个帖要讨论的就是这个。
扯来扯去都快跑题了，在此重申一下。
至于前面所提到的绝对数值，早已声明是没有考究意义的，就连我自己也不太当回事。
其中也就Spring那部分有点现实意义，毕竟运行条件和配置是完全一样的，对于SQL vs ORM还是有点参考意义。
大家有兴趣可以测测自己的系统，这倒是很有必要的。以免过于追新而陷入性能泥潭。
另外有点有趣的是，别看Spring体系下的数值不高，却相当稳当。也就是说，笔者做这些极端测试时，CPU占用必然是99%-100%。在这种极端情况下，用其它客户端访问几乎不见慢，不知是不是共享实例的好处。至于其它的，数值高是高，压力测试下还是见慢了，怀疑是“虚高”。
由此大大恢复了对Spring的信心。近期在筹划一个区域卫生信息共享的计划。琢磨下来，Spring jdbc方案辅以适量的存储过程应该可以搞得定。
1。我不明白为什么CPU占100%
2。上面谁说ORM,jdbc，在说什么orm快，jdbc快,我只知道两个要点 一：我知道orm都是在jdbc上的,二，程序都是耗时间的
上面我已经说过了，没什么服气不服务的问题，因为哪个快一些，哪个慢一些根本就无关紧要。其实我可以做这样的测试，而且事实上我经常私下做各种性能测试，考察不同框架的性能和伸缩性表现。但是测试不同编程语言不同框架速度快一点还是慢一点，这个根本就是没有意义的事情，而且你所谓的感性认识还是个错误的认识，很可能导致你在将来的技术选型和框架设计上做出错误的决定。
我这里也做一做测试，不管是好是赖，放上来让大家讨论一下。顺便鼓励大家都去做一做，好好考量一下自己系统的性能，至于有没有意义大家自己去判定。
如果照你的说法，这种性能测试是根本没有意义的。是不是说现在凡是可以做B/S的，语言和框架快慢是无所谓的事情，也就是说根本不用去选了。既然性能最后都大同小异了，是不是说开发效率才是唯一的标尺。
如此这般的结论，那就还是选择当前开发效率高的RoR了。
可惜，本人在现实工作中，不论是自己开发还是其它厂商的东西，在存储过程、SQL和ORM之间还是有差距的；而众所周知的Spring和EJB之间，也还是有差距的。
比如让RoR做一下库存盘点，医保结算，代码写起来是够清晰的，可惜那个速度......。换存储过程和SQL看看，还说是没有差距吗？
不要觉着是在找碴。企业应用中，尤其是大家这些年看不上眼，以为是过时的SQL+C/S系统里面，这类复杂的业务逻辑太多了。想要改朝换代，先过性能这一关。
如果有不服气的可以实际测测给出数据再说话。
上面我已经说过了，没什么服气不服务的问题，因为哪个快一些，哪个慢一些根本就无关紧要。其实我可以做这样的测试，而且事实上我经常私下做各种性能测试，考察不同框架的性能和伸缩性表现。但是测试不同编程语言不同框架速度快一点还是慢一点，这个根本就是没有意义的事情，而且你所谓的感性认识还是个错误的认识，很可能导致你在将来的技术选型和框架设计上做出错误的决定。
如果有不服气的可以实际测测给出数据再说话。