|
锁定老帖子 主题：硬件越跑越快，软件越陷越慢
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-07
现在大多数人都是因为framework而用framework.
但不可否认优秀的framework用得好,确实能大大提高生产效率.至于系统性能,对于已经非常便宜的硬价格来说,已不是大问题了. |
| 返回顶楼 | |
|
发表时间：2008-05-07
lgx522 写道 icewubin 写道 有吗？为什么你会认为用了framework、ORM、Ioc、AOP就会严重降低，我这里说了是“严重”，慢是慢一点，但是在整个运行时的体系中，这样的慢是可以忽略的，牵涉到优化理论了，打住。 但是我说的慢是是一些固有的慢，比如反射的开销，而且随着JVM的进步，这些开销也在改善，JDK1.4的反射就要比1.2的速度快很多。 但是绝大多数的时候，这个“慢”是使用不当造成的，而不是这些技术带来的，当然大家可说，这些技术的带来了更多的学习成本。 有兴趣的测一下。同一台AppServer机器，同一台DB。先来个小库，弄上十来条记录；再来个大库，弄个几千万条记录。 随便配个连接池，拿jdbc+Servlet+jsp做点CRUD，找个工具测一下，顺便记录一下搞定这些事情的时间。 Spring+XX+XX，再做同样的事情，再测一下。 再测个Grails。 传统EJB就免了，来个时髦的Seam，再测。 Java体系外的，测一测RoR，ASP，ASP.NET，PHP，cakePHP、Zendframework。 顺便提一下缓存的问题： 互联网应用，缓存是个宝，多加内存吧。可惜当前的互联网应用交互性越来越强了，“写”的东西越来越多，缓存也未必能解决多少问题。 企业应用，缓存就免了。以写为主、即时查询统计数据，缓存无用。 测试下来看看每种技术下耗费的开发时间和运行效率，就会感慨Rod Johnson说的“问问机器”。这下子，才知道操作DB的效率是决定因素。如果效率不再重要，大网站也就不会连DB都不用，转回去用文件了。 拐一个弯就慢一点，拐好几个弯就慢得太多。倒不如简单直接，开发、运行和维护都才够快。 说真的，最近是越来越认同Oracle大牛们把业务逻辑放进存储过程的言论了，不仅仅是高效率，同时也是现实可行的高重用。好在MySQL5也可以用存储进程了，大家大可试试这种模式。 当你并发量百万级以上后，软体体系就不完全是这样的了，数据库是很重要，但不是万能的，在整个体系架构设计中，数据库就是一部分而已，最终考虑数据的流向还是要从业务需求来讲的，可以看看如taobao、myspace、土豆网的架构设计。 你刚才写的crud测试代码本身就是有问题的，要在一定的需求前提下讨论，如果拿电信计费这种需求来讨论的话，结果当然如您所说，但是如果用户操作习惯是类似于淘宝这种的话就是另外一回事了。 举个例子，一个较复杂的查询，之所以叫较复杂，是因为更复杂的就应该上搜索引擎了，这个查询可能有10个参数，不同的组合就是10！个sql可能，所以一般都是拼sql，如果正巧拼出来和某一次正好一样，中preparedstatment缓存的话另说了。而且不同的参数关联的表也有可能不一样，拼的过程中还能查询优化。抛砖引玉的例子，也不想说什么其他方式做得不好，只是实现和维护和需求变更的代价非常大而已。 再说缓存，往低的说Hibernate有自己的缓存机制，不过至少我觉的不太够用。一般的程序中可以考虑自行设计一些开发代价很小的缓存机制，比如数据字典的缓存。往大的说，像taobao这种网站的图片等数据，就是要专门设计分布式缓存服务器了，对就像你说的，抛弃了DB，直接转向文件系统，但是把数据从文件系统中读取，放到内存里，然后进行分布式管理和之中优化的算法，这还是软件做的事啊。 语言只是工具，设计模式是让你有更好的代码组织和重用，减少维护工作量，和提高响应速度（如果有这种需求的话）。好的设计模式有时候通常也不是以性能为代价的，甚至于可能有更好的性能。然后就是框架，首先要了解框架，看能利用其中多少，适合于自己的技术体系，或者是适合当前项目的业务特征，并且不使用不适合的部分，就像Spring东西一堆，我们只用其中小部分而已。 但是如果测试是按照什么教科书上的那些方式还是免了吧，实际项目中是不会这么做的。 |
| 返回顶楼 | |
|
发表时间：2008-05-07
icewubin 写道 lgx522 写道 icewubin 写道 有吗？为什么你会认为用了framework、ORM、Ioc、AOP就会严重降低，我这里说了是“严重”，慢是慢一点，但是在整个运行时的体系中，这样的慢是可以忽略的，牵涉到优化理论了，打住。 但是我说的慢是是一些固有的慢，比如反射的开销，而且随着JVM的进步，这些开销也在改善，JDK1.4的反射就要比1.2的速度快很多。 但是绝大多数的时候，这个“慢”是使用不当造成的，而不是这些技术带来的，当然大家可说，这些技术的带来了更多的学习成本。 有兴趣的测一下。同一台AppServer机器，同一台DB。先来个小库，弄上十来条记录；再来个大库，弄个几千万条记录。 随便配个连接池，拿jdbc+Servlet+jsp做点CRUD，找个工具测一下，顺便记录一下搞定这些事情的时间。 Spring+XX+XX，再做同样的事情，再测一下。 再测个Grails。 传统EJB就免了，来个时髦的Seam，再测。 Java体系外的，测一测RoR，ASP，ASP.NET，PHP，cakePHP、Zendframework。 顺便提一下缓存的问题： 互联网应用，缓存是个宝，多加内存吧。可惜当前的互联网应用交互性越来越强了，“写”的东西越来越多，缓存也未必能解决多少问题。 企业应用，缓存就免了。以写为主、即时查询统计数据，缓存无用。 测试下来看看每种技术下耗费的开发时间和运行效率，就会感慨Rod Johnson说的“问问机器”。这下子，才知道操作DB的效率是决定因素。如果效率不再重要，大网站也就不会连DB都不用，转回去用文件了。 拐一个弯就慢一点，拐好几个弯就慢得太多。倒不如简单直接，开发、运行和维护都才够快。 说真的，最近是越来越认同Oracle大牛们把业务逻辑放进存储过程的言论了，不仅仅是高效率，同时也是现实可行的高重用。好在MySQL5也可以用存储进程了，大家大可试试这种模式。 当你并发量百万级以上后，软体体系就不完全是这样的了，数据库是很重要，但不是万能的，在整个体系架构设计中，数据库就是一部分而已，最终考虑数据的流向还是要从业务需求来讲的，可以看看如taobao、myspace、土豆网的架构设计。 你刚才写的crud测试代码本身就是有问题的，要在一定的需求前提下讨论，如果拿电信计费这种需求来讨论的话，结果当然如您所说，但是如果用户操作习惯是类似于淘宝这种的话就是另外一回事了。 举个例子，一个较复杂的查询，之所以叫较复杂，是因为更复杂的就应该上搜索引擎了，这个查询可能有10个参数，不同的组合就是10！个sql可能，所以一般都是拼sql，如果正巧拼出来和某一次正好一样，中preparedstatment缓存的话另说了。而且不同的参数关联的表也有可能不一样，拼的过程中还能查询优化。抛砖引玉的例子，也不想说什么其他方式做得不好，只是实现和维护和需求变更的代价非常大而已。 再说缓存，往低的说Hibernate有自己的缓存机制，不过至少我觉的不太够用。一般的程序中可以考虑自行设计一些开发代价很小的缓存机制，比如数据字典的缓存。往大的说，像taobao这种网站的图片等数据，就是要专门设计分布式缓存服务器了，对就像你说的，抛弃了DB，直接转向文件系统，但是把数据从文件系统中读取，放到内存里，然后进行分布式管理和之中优化的算法，这还是软件做的事啊。 你举的例子都是网站，他们静态内容多，可以缓存，但是企业应用不同于网站。 网站方面，也就是ebay和淘宝用java架构，其他的，google，youtube，facebook，wiki等都不是java架构。 |
| 返回顶楼 | |
|
发表时间：2008-05-07
ztka 写道 你举的例子都是网站，他们静态内容多，可以缓存，但是企业应用不同于网站。
怎么会都是静态的，我还特地举淘宝的例子，图片我只是单独拿出来说，图片信息本身就是动态的，不同的卖家发布新的商品的图片更新。 1.你只用数据库存储过程，你设计一个taobao这样的网站试试？数据库能搞定多少问题，这种数据库方案也不过是利用（或者说迷信）数据库的同步机制罢了，和那些迷信J2EE所谓的高效同步机制有什么本质区别。 2.即使不说大网站，企业软件，并发上个50-200也是蛮正常的吧，刚才说了，用个结构很简单的数据字典缓存机制根据需求就能极大的改善性能，而且开发量相对不大，但用数据库结构做的到么。我的意思是系统复杂度达到一定程度，不好好设计整体的话，开发复杂的，代码（不管什么代码）复杂度，维护成本是以几何级数往上翻的。 |
| 返回顶楼 | |
|
发表时间：2008-05-07
icewubin 写道 ztka 写道 你举的例子都是网站，他们静态内容多，可以缓存，但是企业应用不同于网站。
怎么会都是静态的，我还特地举淘宝的例子，图片我只是单独拿出来说，图片信息本身就是动态的，不同的卖家发布新的商品的图片更新。 1.你只用数据库存储过程，你设计一个taobao这样的网站试试？数据库能搞定多少问题，这种数据库方案也不过是利用（或者说迷信）数据库的同步机制罢了，和那些迷信J2EE所谓的高效同步机制有什么本质区别。 2.即使不说大网站，企业软件，并发上个50-200也是蛮正常的吧，刚才说了，用个结构很简单的数据字典缓存机制根据需求就能极大的改善性能，而且开发量相对不大，但用数据库结构做的到么。我的意思是系统复杂度达到一定程度，不好好设计整体的话，开发复杂的，代码（不管什么代码）复杂度，维护成本是以几何级数往上翻的。 你理解的静态是什么？一直不会变得东西？ 你用过squid吗？ 以数据为核心设计，不是说只用存储过程。 你说淘宝架构，我用php+mmcache+squid+lvs+mysql等就可以实现，成本比你的java至少少50%，开发成本少50% |
| 返回顶楼 | |
|
发表时间：2008-05-07
引用 由于是在单位上混，出于饭碗的需要，几年来不得不参加了当初以为“不切实际”的软考，一直混到系统分析师。回头看下来，这些个“不切实际”的学究体系其实反倒有些有用处。硬着头皮大体上啃了一遍学究知识，最后才搞明白程序要快要稳定，还是要搞清楚CPU、内存和硬盘；而所谓的可靠性、重用性、扩展性、...XX性，不是靠什么具体的软件技术，而是在于规范的管理与审慎的规划。
对于国内的程序员有很有教育意义！础性的知识不可缺乏，否则只能玩儿玩儿而已！ |
| 返回顶楼 | |
|
发表时间：2008-05-07
mcpssx 写道 缓存都是些赶时髦的，
企业应用还缓存个P？WEB应用会用什么hibernate缓存吗？ java的Web开发 用 XML说可配置， 用JAVA不用SQL说数据库可移植， 分N多层还说可维护， 关系模型不用去转换成什么对象模型， 最后被一群phper草根乱拳打死老师傅 企业应用为什么不能用缓存，以很小的代价获得高性能回报，为什么不用？ 二级缓存先不提，hibernate一级缓存（一个事物中的缓存）就能直接减少数据库的访问次数，当然有用。 不要老说web开发，那只是“平原型”的项目，如果是“深井型”的项目，或者后台逻辑稍微一复杂，重点就不是web开发了。 XML可配置，现在不流行的，java框架也可以进步的，思想本来就可以借鉴的嘛。 可移植当然重要，难道你自己写针对不同数据高效的分页算法么？你不要告诉我什么项目定了，数据库就定了，我见过太多的更换数据库的例子，还就是做产品的话，怎么能不考虑数据库的多样性。 分N层不很正么，比如事务层，aspectJ配好就完事，一劳永逸有什么不好，难道自己不停的写begin transaction、end transaction么？你用数据库如何实现灵活的事务传播机制，难道不停的复制粘贴代码么，可维护性好么？ phper草根乱拳，我不否认任何语言的存在合理性。 1.思想可以互相借鉴，比如约定大于配置的思想。 2.技术的繁荣那个程度的因素不是有时否是“草根”决定的，非技术的因素太多了，说起来Hibernate不也是“草根”出身么？为什么phper的草根就比别人高贵么？ |
| 返回顶楼 | |
|
发表时间：2008-05-07
ztka 写道 回归到楼主的话题，为什么很多人说hibernate什么用起来不慢，他们碰不到数据量比较大的场景
数据量大的场景的使用方法就不是教科书上的那种了，数据量大必须要结合具体的需求来分析。 |
| 返回顶楼 | |
|
发表时间：2008-05-07
我说你那种hibernate的架构，我用php开发，维护成本比你低，开发时间不比你多，你觉得你的hibernate优势在哪里？忽悠？
|
| 返回顶楼 | |
|
发表时间：2008-05-07
mcpssx 写道 lgx522 写道 balan 写道 很多软件新技术的出现，初衷并不是运行的更快，而是开发的更快，响应需求变化更快，扩展和维护更快。
做软件，最终目的是要开发得快、维护得快、运行得快。做出来的系统费了比别人多几倍的时间，硬件费了几倍的钱，最后还比别人跑得慢，维护起来要折腾好几个弯弯，再多的大词也只能自欺欺人。 本人其实正是这些大词的迷信者，折腾了几年才知道是怎么回事。 说点闲话，JE的很多牛人为何都倒戈RoR，这已经是耐人寻味了。 本人RoR实践了半年，说句实话，除了性能，什么都好。但这一缺点，对于以写为主的企业应用基本上可以毙了。 JE的很多牛人就是穷折腾，你回头看看以前他们鼓吹的各种框架， RoR我看也是三分钟的热度。 php都能解决的事情，非要玩什么open class，闭包 ztka 写道 我说的，你那种hibernate的架构，我用php开发，维护成本比你低，开发时间不比你多，你觉得你的hibernate优势在哪里？忽悠？
ztka，能比较下php和rails的ActiveRecord吗？对这个话题比较感兴趣。也许，应该单独开个贴。 |
| 返回顶楼 | |
