rails电子商务

① 范凯的个人观点

来自范凯的个人博客 因为看到一篇讨论PHP，Python和Ruby的编程语言讨论贴，就说说我的PHP，Python和Ruby之路吧：
我2000-2001年用PHP用了两年，那还是第一次互联网泡沫时期，到2001年后期，Servlet/JSP流行，然后我就发现：你说用PHP写的东西，都会被人鄙视。当时我们其实也用Java了，只不过用Java写后端的消息队列。
2001年后期泡沫破灭，我跑去做企业应用，就主要写Java写了很多年，中间2003年开始做JavaEye网站，到2006年用Rails重写JavaEye之前的3年，用的是phpbb搭建的，所以PHP也断断续续一直用到了2006年。
以我2000-2006年总共六年多的使用体验来说，我对PHP真的是深恶痛绝之，但凡做一个稍微大一点的系统，代码就很容易失控。2002年以后，我曾经一度以为PHP这个东西快死掉了，那个时候大家都言必称J2EE和.net了。结果Web2.0之风袭来，大家又发现J2EE太重，PHP又死灰复燃了，我其实很诧异现在PHP居然又变得如此流行。从技术上来讲，PHP是个很烂的东西，但它门槛低，易部署，普及率高，好找人，实在是互联网时代的VB，打不死的小强。
Python我大概是04-05年迷恋了一年左右，研究过Zope，plone，后来还看过wxPython，曾经一度想用Python写JavaEye网站。记得04年Rails出来之后，还很长一段时间被我深深鄙视过。
但后来我去杭州拜访potian，被他的Rails实践经验说服了，之后我和他以及其他人在JavaEye上面有一个很长的讨论贴，讨论Rails的运行机制，最后我又被他说服了。然后我还不死心，研究和比较了Rails和Django，不得不死心了，后来还曾经几次想用Python，每次都死心的很彻底，现在就彻底不考虑Python了。
就算你不用Rails，作为一个程序员，我也强烈建议你学习一下Ruby，仅仅因为可以开拓你的思维就很值得了。因为Ruby的语法很强大很好玩，是现代语言版本的smalltalk，算是很原汁原味的面向对象编程语言，你学习了Ruby以后，你就会发现，原来Java/C++所谓的面向对象就是TMD的山寨版本的面向对象，原来面向对象还可以这样玩阿。
PHP用一句话来总结就是：quick and dirty
Python用一句话来总结就是：quick and clean,but not convenient for web development
Ruby用一句话来总结就是：code for fun and quick for web
补充一下吧：为什么我当初用Rails来写JavaEye网站：
在选择用什么工具开发JavaEye网站的时候，唯一的指导标准就是：用最少的人力，最少的时间开发JavaEye网站，并且后期维护和持续升级，乃至重写的时候，代价最小。
首先排除Java和C#，代码太多太麻烦；
其次排除PHP，项目一大，代码一多，代码的管理很成问题，PHP缺乏一个起码的包管理机制；
当时重点考察Python和Ruby，因为有豆瓣的先例，开始很倾向于Python，而且我那个时候对Python比较熟悉，还曾经痴迷过一段时间的wxPython，对Zope和plone也有一些研究。
但后来比较了Rails和Django之后，就倾向于Rails了，差距实在太大了，而且当时Django很不成熟，在很早期的版本。其实即便现在Django和Rails的差距也没有缩小过。
但让我最终下定决心的是potian在05年就大规模使用Rails的实际工程经验，我曾经去杭州就我比较质疑的问题当面请教过他，和他谈过以后，就决定用Rails了。
应该说，我当初用Rails的决定很英明！ 在四年以前，当我开始鼓吹Hibernate，抨击EJB的时候，遭到的是群起而攻之的场面，但是不到一年之后，Hibernate已然得到了普及和大多数Java开发人员的认可；
在三年以前，当我开始赞誉spring的时候，spring还面临着EJB3的阴影，以及EJB2对其不登大雅之堂的指责，然而不到一年的时间，spring已经成为绝大多数Java开发人员的首选；
在两年以前，我极力希望宣传webwork，唱衰JSF，时至今日，webwork以Struts2.0的身份容登大雅之堂，而JSF还在靠厂商死挺着；
而当一年之前我开始采用RoR开发JavaEye的时候，RoR的置疑之声还甚嚣尘上，但当我在今年初预言07年下半年RoR在国内会被广泛接受的时候，很多人已经笑不出来了；
今年我预言些什么呢？我觉得会是AJAX技术走出PC的时代，证据就是iphone，与此相关联的事情就是REST架构的流行。
但是这篇文章里面我想谈的却不是我预言的水平准不准，而是想谈Java真的会因为RoR的流行而过时吗？目前在web开发主要应用在两个大的领域，互联网和企业应用，我们分别来看一下：
一、互联网领域
互联网领域第一大动态语言是PHP，第二第三分别是ASP和Java。在中小型互联网应用当中，PHP的王者地位不容动摇，但在大型应用当中，Java是目前主流的选择，特别是电子商务类型的应用，例如阿里巴巴就从早期的PHP转变到Java，从前的eachnet也是如此。造成这样局面不是没有原因的：
1．中小型互联网网站强调开发速度，维护成本，以及入门快速和部署成本，PHP是最合适的选择；用Java则显得过于笨拙，开发慢，维护成本高，入门周期长，部署麻烦；RoR开发速度最快，维护成本最低，但是RoR入门速度没有PHP快，部署成本比PHP高。因此中小型互联网网站主流还是PHP，但RoR能够占据一定的份额。
2．大中型互联网站强调稳定性，性能，大规模代码的组织能力，而开发效率则退居次要地位，有些应用如电子商务对事务有很高的要求，显然Java是最合适的选择；PHP的代码组织能力最差，RoR次之。
在互联网领域，Java从来就不是主流，并且Java的适用领域和RoR不太重合。我们甚至可以这样说，RoR现在在互联网领域取代的是那些原本不适合用Java，但是被错误的选择了Java的项目。
二、企业应用领域
目前企业应用领域第一大语言是Java，dotnet其次。企业应用采用的技术和行业有很大关系：例如金融行业，电子政务行业一般只采用Java。dotnet发展了6年尚且没有进入企业高端的应用，RoR在短期之内也很难取代Java的地位。
在企业应用领域，Java是主流，并且Java的适用领域和RoR也不太重合。我们也可以这样说，RoR将来在企业应用领域要取代的是那些原本不适合用Java，但是被错误的选择了Java的项目。
至此，我想Java程序员大可以松一口气，RoR目前有哪些不适合的场合呢：
1．对事务要求非常高的场合
RoR还是很简单的单数据库事务控制，缺乏精细的事务控制功能，当然也不支持跨数据库的分布式事务。因此对于事务要求严格的大型电子商务网站，部署复杂的分布式数据库场景显得力不从心。当然也许有些plugin可以提供这些功能，但是从目前的功能完备性和成熟度来看，还不够。
2．处理大量遗留数据库的场合
ActiveRecord的威力很大程度上来自约定，大量命名糟糕的遗留数据库会对RoR造成比较大的障碍。
3．庞大的项目团队，对开发速度要求低的场合
例如日本外包项目，团队庞大，个体开发速度要求低。但是对于代码规范要求严格的项目。
虽然RoR不会取代Java，但不意味着作为程序员的你可以固步自封。即使在工作当中用不上RoR，多看一点新的技术，对于开阔个人视野也有很大的好处。 挺有意思的现象
记得过去还没有创办JavaEye的时候，在技术社区里面推广Hibernate(也算不上是推广，只是和别人交流Hibernate)，就有一大批人酸酸的跳出来说，你们今天学习这个明天学习那个框架，全都是跟风，这些框架都是浮云，真正JDBC这种基础知识才是实力的，我就用JDBC，我用的一直很好，我完全没有必要去学习Hibernate……
每当看到这种话，我就觉得特别好笑，用一个我发明的说法叫做“牛逼哄哄的露怯”。没有人逼你学习Hibernate，你不乐意关心Hibernate，那就继续用JDBC好了，这个世界从来都不是非黑即白的。
其实这种人的心态很有意思。他一方面眼红人家学习新的技术，另一方面自己又不想花时间和代价去学习，所以恨不得所有的人都不要去学习新技术，这样他心里就感觉很安全了，正因为如此，他就总是要时不时跳出来打击一下别人，表面上很牛逼，其实虚弱的内心挣扎一览无余。
如果想把技术作为终身职业，那么对于技术人员的起码要求就是不能固步自封，要始终以开放的心态接受新技术。
打好基础知识固然重要(重要到根本无需你一遍又一遍的祥林嫂)，但是不接触新技术，新思路，新的理念，很快就会被淘汰掉。
当然学习新技术也不是盲目的什么都学习，什么流行学习什么，而是根据自身的需要，有选择的学习。例如Java Web框架有很多很流行的，Struts，Webwork，Spring MVC，Tapestry，JSF，主流的就有5个，盲目的学习者就是人家说什么他就学什么了。而聪明的学习者应该对这些东西都去接触一下，从中选择一个值得自己投资时间成本去学习的框架。例如对这五个框架我都涉猎过一遍，最终我把时间花在了Webwork上面，事实也证明我当初的投资是正确的。
我学习ruby on rails有很现实的需要，其实即便抛开现实的需要，我也认为如果有空，Java开发人员有必要学习一下，原因是：
1、ruby语言和rails框架的社区力量正在以惊人的速度增长，甚至已经进入爆炸式繁荣的前夜，这不是昙花一现的现象，而是一个时代开始的象征。
2．从我这段时间学习的情况来看，ruby语言有足够的学习深度，我原来以为自己一个很快速的上手，然后就很精通了，但是ruby不像PHP那种方便面，其知识的广度和深度都让我感觉这是一个完整的知识体系。也正因为如此，ruby生命力会很长。
3． ruby和rails是非常非常Unix-like的东西，经常和操作系统提供的功能有深度的依赖，这和Java这种不依赖操作系统，什么基础设施都自己卷起袖子自己创造的理念相比，非常非常的不同。这样做会带来一个很大的好处，很多在Java里面解决方案很复杂的问题，在ruby方案中就很简单可以搞定，相比之下，让Java显得颇为大而无当。
不过ruby和rails也树立起了一堵墙，这堵墙就是Unix操作系统，要学好我，你就先跨越Unix这堵墙吧。呵呵，这也是为什么rails core team清一色的MacOSX的原因了。
不过我觉得这是好事，我本人是Unix fans，乐意见到这种现象，况且凭借我多年深厚的Unix功底，在ruby fans中，我又站在了一个很高的起点上领跑了。
想学好ruby吗？先在你的电脑上面安装MacOSX/ubuntu作为开发环境咯。 孟岩最近写了一篇博客：
Ruby 1.9不会杀死Python
这篇文章很有点标题党的意思，所以在JavaEye论坛很快被水掉了，只好锁贴：
但我个人对于孟岩的观点是不敢苟同的。首先我并不同意所谓魔幻语言和简约语言的分类。其实Martin Flower论述过这个问题，他是用“人性化接口”和“最小接口”来区分编程语言的风格化差异的。
其实不用我多说，Martin论述的挺充分了。强把Ruby和C++归为魔幻一类，其实并不准确，因为Ruby的魔幻语法和C++相比，最大区别在于：
C++的魔幻语法会导致代码的可读性变差，而Ruby的魔幻语法会导致代码的可读性大大提高。
不论是matz本人，还是整个Ruby社区，Rails社区诸多开源项目的作者，抑或整个Ruby和Rails开发者社区，在一个编程哲学问题上是高度统一的，这就是：
强调程序员的快乐编程，追求人性化编程，在代码的可读性上面有偏执的追求，拒绝难以阅读的代码和难用的API。也就是所谓的coding for fun!
所以你看无论是Rails，rake，rspec，甚至移植自lucene的ferret，都鲜明的体现出来这种特点，就是API简单好用，让你写的代码像英文文章，自然流畅，轻松愉快。要是哪个Ruby框架的API复杂晦涩，在Ruby社区简直没法混，大家根本不买他的帐，这也是为什么Ruby应用于DSL领域这么热的根本原因。
对于ruby程序员来说，这种追求编程人性化的哲学理念会潜移默化影响程序员，让他不知不觉把代码的可读性越写越好。对于程序员来说，谁不想coding for fun呢？ 而当你品尝到了coding for fun的乐趣，又怎么会轻易抛弃？
所以Ruby受程序员欢迎的根本原因还是在于它是一种能给你带来编程乐趣的语言。 有人说，robbin你说了那么多RoR的优点，你啥时候说说RoR的缺点阿？你说的缺点肯定比别人说的更客观。没办法，为了表现出来我不是一个RoR粉，只好总结点缺点，以飨RoR黑子们：
Ruby和Rails的一些缺点的总结：
ruby的问题我觉得主要是：
1．ruby本身的性能是比较差的，无法直接做一些计算密集型的任务
比方说大量的分词运算、语料训练什么的，用ruby写是不行的
2．ruby的C扩展很难写
正因为ruby性能差，所以很多情况下要依赖C写的底层库，但是写ruby的扩展C库是很困难的事情。一方面没有特别多的资料介绍，你能参考的只有《Ruby Hacking Guide》，另外一方面Ruby是带有GC的语言，C又是没有GC的，所以如果你对ruby的GC机制没有特别清楚的了解情况下，写C扩展会出现意想不到的问题：比方说你写的程序逻辑没有任何问题，但是和ruby配合起来就会不定期的出现错误，这就是你C程序的某个赋值变量可能会被ruby GC以你意想不到的方式销毁。
3．ruby的C扩展库质量不高，容易出现内存泄漏问题
正因为上面的原因，很多第三方的C扩展库质量不好，很容易出现内存泄漏问题，这是一个很头疼的问题，你很难定位，也很难解决，只能尽量避免使用第三方扩展C库。
Rails的问题我觉得主要是：
1．特别容易出现命名冲突
你自己写的代码里面给类增加的方法，动不动就和Rails给类扩展的方法名称冲突了。这种错误很隐蔽，很难发现。这也是ruby语言动态性带来的一个负面影响
2．Rails每次升级API变动都比较大
Rails升级是不太考虑向下兼容性的，所以每次升级的话，可能你很多代码都要改，更糟糕的是很多Rails插件特别喜欢以hack rails的方式来扩展Rails功能，那么Rails一升级，插件的兼容性几乎肯定是不行的，这个是比较痛苦的事情。
3．Rails的view方面还是比较原始的erb拼接字符串方式，像JSP那样原始，没有一个类似Java的velocity/freemarker那样的页面模版库，所以写helper动不动要用字符串去拼html片断，如果是特别复杂的view需要拼的话，代码就会写的很丑陋。
当然总体来说，RoR还是让我感觉非常满意的，特别适合互联网应用。 从无到有刚开始做一个网站或者一个产品，要非常聚焦，没有旁的多余功能，只有一个做的极其牛X的核心功能，牛X到别人没有办法模仿你，于是网站开始崭露头角；
等核心功能成功以后，网站开始声名鹊起，为了扩展用户规模，产品开始多元化，各种各样时髦功能，各种各样用户要求的功能纷纷上马，于是用户规模开始快速扩张；
等用户规模已经起来之后，开始聚焦商业目标，于是删繁就简，开始砍掉与商业目标不符合的枝节功能，加强和商业目标符合的核心功能，网站进入健康的商业循环；
大部分网站都可以做到第一个阶段，但其中大部分都会倒在第二个阶段，而迈过第二阶段能够做到第三个阶段的就凤毛麟角了。到了第三个阶段，一个产品才真正开始成熟起来，才具有顽强的生命力，在IT垂直领域里面，JavaEye处于第二个阶段，需要向第三个阶段转变。
也曾经盲目的想把JavaEye的规模做到行业最大，于是上了各种各样的产品和功能，很多都没有细化和雕琢，现在想来都有些多余，而符合商业目标的核心功能又用力不足。现在总算想明白一个道理：规模最大又如何？还是不赚钱。所以接下来怎么做就很清楚了。
另外一条思路是做平台，互联网的未来生态系统肯定是由平台和内容提供商构成的，你要么做平台，要么做内容提供商。但在IT垂直领域，用户规模和市场空间过于狭小，平台没有足够的空间生存，所以这条路不通。不要企图做大而全的门户，不要企图做无所不包的平台。
定位好目标，不要做无关的功能，突出符合商业目标的核心功能和产品，足矣！

② php,jsp,asp三者优缺点...

JSP ASP PHP
运行速度 快 较快 较快
运行耗损 较小 较大 较大
难易程度 容易掌握 简单 简单
运行平台 绝大部分平台均可 Windows平台 Windows/UNIX平台
扩展性 好 较好 较差
安全性 好 较差 好
函数性 多 较少 多
数据库支持 多 多 多
厂商支持 多 较少 较多
对XML的支持 支持 不支持 支持
对组件的支持 支持 支持 不支持
对分布式处理的支持 支持 支持 不支持
应用程序 较广 较广 较广
----------------------------------------------------
转载:
慢慢看吧!
ASP、JSP与PHP的比较

目前，最常用的三种动态网页语言有ASP(Active Server Pages),JSP(Java Server Pages),
PHP (Hypertext Preprocessor)。

简 介

ASP全名Active Server Pages，是一个WEB服务器端的开发环境， 利用它可以产生和运
行动态的、交互的、高性能的WEB服务应用程序。ASP采用脚本语言VB Script（Java script
）作为自己的开发语言。

PHP是一种跨平台的服务器端的嵌入式脚本语言. 它大量地借用C,Java和Perl语言的语法
, 并耦合PHP自己的特性,使WEB开发者能够快速地写出动态生成页面.它支持目前绝大多数数
据库。还有一点，PHP是完全免费的，不用花钱，你可以从PHP官方站点(
t)自由下载。而且你可以不受限制地获得源码，甚至可以从中加进你自己需要的特色。

JSP 是Sun公司推出的新一代站点开发语言，他完全解决了目前ASP,PHP的一个通病－－
脚本级执行（据说PHP4 也已经在Zend 的支持下，实现编译运行）.Sun 公司借助自己在Jav
a 上的不凡造诣，将Java 从Java 应用程序 和 Java Applet 之外，又有新的硕果，就是Js
p－－Java Server Page。Jsp 可以在Serverlet和JavaBean的支持下，完成功能强大的站点
程序。

三者都提供在 HTML 代码中混合某种程序代码、由语言引擎解释执行程序代码的能力。
但JSP代码被编译成 Servlet 并由 Java 虚拟机解释执行，这种编译操作仅在对 JSP 页面的
第一次请求时发生。在 ASP 、PHP、JSP 环境下， HTML 代码主要负责描述信息的显示样式
，而程序代码则用来描述处理逻辑。普通的 HTML 页面只依赖于 Web 服务器，而 ASP 、PH
P、JSP 页面需要附加的语言引擎分析和执行程序代码。程序代码的执行结果被重新嵌入到
HTML 代码中，然后一起发送给浏览器。 ASP 、PHP、 JSP三者都是面向 Web 服务器的技术
，客户端浏览器不需要任何附加的软件支持。

技术特点

ASP:

1. 使用 VBScript 、 JScript 等简单易懂的脚本语言，结合 HTML 代码，即可快速地完成
网站的应用程序。
2. 无须 compile 编译，容易编写，可在服务器端直接执行。
3. 使用普通的文本编辑器，如 Windows 的记事本，即可进行编辑设计。
4. 与浏览器无关 (Browser Independence), 用户端只要使用可执行 HTML 码的浏览器，即
可浏览 Active Server Pages 所设计的网页内容。 Active Server Pages 所使用的脚本语
言 (VBScript 、 Jscript) 均在 WEB 服务器端执行，用户端的浏览器不需要能够执行这些
脚本语言。
5.Active Server Pages 能与任何 ActiveX scripting 语言相容。除了可使用 VBScript
或 JScript 语言来设计外，还通过 plug－in 的方式，使用由第三方所提供的其他脚本语言
，譬如 REXX 、 Perl 、 Tcl 等。脚本引擎是处理脚本程序的 COM(Component Object Mod
el) 物件。
6. 可使用服务器端的脚本来产生客户端的脚本。
7.ActiveX Server Components(ActiveX 服务器元件 ) 具有无限可扩充性。可以使用 Vi
sual Basic 、 Java 、 Visual C＋＋ 、 COBOL 等编程语言来编写你所需要的ActiveX Se
rver Component 。

PHP:

1．数据库连接
PHP可以编译成具有与许多数据库相连接的函数。PHP与MySQL是现在绝佳的组合。你还可
以自己编写外围的函数取间接存取数据库。通过这样的途径当你更换使用的数据库时，可以
轻松地更改编码以适应这样的变。PHPLIB就是最常用的可以提供一般事务需要的一系列基库
。但PHP提供的数据库接口支持彼此不统一，比如对Oracle, MySQL， Sybase的接口，彼此
都不一样。这也是PHP的一个弱点。
2．面向对象编程
PHP提供了类和对象。基于web的编程工作非常需要面向对象编程能力。PHP支持构造器、
提取类等。

JSP:

1．将内容的生成和显示进行分离
使用JSP技术，Web页面开发人员可以使用HTML或者XML标识来设计和格式化最终页面。使
用JSP标识或者小脚本来生成页面上的动态内容。生成内容的逻辑被封装在标识和JavaBeans
组件中，并且捆绑在小脚本中，所有的脚本在服务器端运行。如果核心逻辑被封装在标识和
Beans中，那么其他人，如Web管理人员和页面设计者，能够编辑和使用JSP页面，而不影响内
容的生成。
在服务器端，JSP引擎解释JSP标识和小脚本，生成所请求的内容（例如，通过访问Java
Beans组件，使用JDBCTM技术访问数据库，或者包含文件），并且将结果以HTML（或者XML）
页面的形式发送回浏览器。这有助于作者保护自己的代码，而又保证任何基于HTML的Web浏览
器的完全可用性。
2．强调可重用的组件
绝大多数JSP页面依赖于可重用的，跨平台的组件（JavaBeans或者Enterprise JavaBea
nsTM组件）来执行应用程序所要求的更为复杂的处理。开发人员能够共享和交换执行普通操
作的组件，或者使得这些组件为更多的使用者或者客户团体所使用。基于组件的方法加速了
总体开发过程，并且使得各种组织在他们现有的技能和优化结果的开发努力中得到平衡。
3．采用标识简化页面开发
Web页面开发人员不会都是熟悉脚本语言的编程人员。JavaServer Page技术封装了许多
功能，这些功能是在易用的、与JSP相关的XML标识中进行动态内容生成所需要的。标准的JS
P标识能够访问和实例化JavaBeans组件，设置或者检索组件属性，下载Applet，以及执行用
其他方法更难于编码和耗时的功能。
通过开发定制化标识库，JSP技术是可以扩展的。今后，第三方开发人员和其他人员可以
为常用功能创建自己的标识库。这使得Web页面开发人员能够使用熟悉的工具和如同标识一样
的执行特定功能的构件来工作。
JSP技术很容易整合到多种应用体系结构中，以利用现存的工具和技巧，并且扩展到能够
支持企业级的分布式应用。作为采用Java技术家族的一部分，以及Java 2（企业版体系结构
）的一个组成部分，JSP技术能够支持高度复杂的基于Web的应用。
由于JSP页面的内置脚本语言是基于Java编程语言的，而且所有的JSP页面都被编译成为
Java Servlet，JSP页面就具有Java技术的所有好处，包括健壮的存储管理和安全性。
作为Java平台的一部分，JSP拥有Java编程语言“一次编写，各处运行”的特点。随着越
来越多的供应商将JSP支持添加到他们的产品中，您可以使用自己所选择的服务器和工具，更
改工具或服务器并不影响当前的应用。

应用范围

ASP是Microsoft开发的动态网页语言，也继承了微软产品的一贯传统——只能运行于微软
的服务器产品,IIS (Internet Information Server) (windows NT)和PWS(Personal Web Se
rver)(windows 98)上。Unix下也有ChiliSoft的插件来支持ASP，但是ASP本身的功能有限，
必须通过ASP＋COM的组合来扩充，Unix下的COM实现起来非常困难。

PHP3可在Windows,Unix,Linux的Web服务器上正常运行,还支持IIS,Apache等通用Web服务器
,用户更换平台时,无需变换PHP3代码,可即拿即用.

JSP同PHP3类似，几乎可以运行于所有平台。如Win NT,Linux,Unix. NT下IIS通过一个插
件，例如JRUN或者ServletExec，就能支持JSP。著名的Web服务器Apache已经能够支持JSP。
由于Apache广泛应用在NT、Unix和Linux上，因此JSP有更广泛的运行平台。虽然现在NT操作
系统占了很大的市场份额，但是在服务器方面Unix的优势仍然很大，而新崛起的Linux更是来
势不小。从一个平台移植到另外一个平台，JSP和JavaBean甚至不用重新编译，因为Java字节
码都是标准的与平台无关的。

性能比较

有人做过试验，对这三种语言分别做循环性能测试及存取Oracle数据库测试。

在循环性能测试中，JSP只用了令人吃惊的四秒钟就结束了20000＊20000的循环。而ASP
、PHP测试的是2000＊2000循环（少一个数量级），却分别用了63秒和84秒。（参考PHPLIB）
。

数据库测试中，三者分别对 Oracle 8 进行 1000 次 Insert,Update,Select,和Delete
： Jsp 需要 13 秒，Php 需要 69 秒，ASP则 需要 73 秒。

前景分析

目前在国内PHP与ASP应用最为广泛。而JSP由于是一种较新的技术，国内采用的较少。但在
国外，JSP已经是比较流行的一种技术，尤其是电子商务类的网站，多采用JSP。
采用PHP的网站如新浪网（sina）、中国人（Chinaren）等,但由于PHP本身存在的一些缺
点，使得它不适合应用于大型电子商务站点，而更适合一些小型的商业站点。
首先，PHP缺乏规模支持。其次，缺乏多层结构支持。对于大负荷站点，解决方法只有一
个：分布计算。数据库、应用逻辑层、表示逻辑层彼此分开，而且同层也可以根据流量分开
，组成二维阵列。而PHP则缺乏这种支持。还有上面提到过的一点，PHP提供的数据库接口支
持不统一，这就使得它不适合运用在电子商务中。
ASP和JSP则没有以上缺陷，ASP可以通过Microsoft Windowsd的COM/DCOM获得ActiveX规
模支持，通过DCOM和Transcation Server获得结构支持；JSP可以通过SUN Java的Java Clas
s和EJB获得规模支持，通过EJB/CORBA以及众多厂商的Application Server获得结构支持。

三者中，JSP应该是未来发展的趋势。世界上一些大的电子商务解决方案提供商都采用J
SP/Servlet。比较出名的如IBM的E－business，它的核心是采用JSP/Servlet的WebSphere；
西方另外一个非常著名的电子商务软件提供商，Intershop。它原来的产品Intershop1 2, 3
, 4占据了主要的电子商务软件份额。它们都是通过CGI来提供支持 的。但去年10月后它推出
了Enfinity，一个采用JSP/Servlet的电子商务Application Server，而且声言不再开发传统
软件。

总之
ASP，PHP,JSP三者都有相当数量的支持者，由此也可以看出三者各有所长。正在学习或
使用动态页面的朋友可根据三者的特点选择一种适合自己的语言。