关于系统性能的思考

楼上几位一点都不实在。 从技术角度出发讨论问题比较好。

呵呵 我相信很多人都有这么一种感觉,就是不愿意维护以前的系统,如果允许的话宁愿重新开放. 其实很多时候重新开放并不是使用新的技术,恰恰相反很多时候重新开放就是在脱衣服,减轻原有系统.其实这是一种业务理解的提升. 因为你接触这个业务的高度不一样了.你是站在前人的基础上进行业务分析.
所以我不同意楼上的说法,如果单从技术角度去解决性能的问题终极还是有瓶颈的,当然我这种想法是不现实的,因为业务的重新挖掘其实就是一个重新开发的过程( 当然你可以说是重构)
总之一句话,最原始的业务模型抽象已经决定了你系统的性能大小.

呵呵，请问一下有几个软件公司是单纯靠技术生存的。做企业级开发的软件公司不一定都是技术很好，人家也许技术一般般，但是人家对某个领域的业务非常熟悉，在业务上的精通再加上人家一般般的技术照样可以做出让客户满意的系统。技术虽然重要，但是请别忽视真正软件的核心：业务，领域模型。也许技术都换了很多代，但是核心的领域模型还是不变的。

同意。
  没有不能实现的技术。你能想到的 技术都可以实现。从当初的web1.0的静态页到现在的动态交互，从当初的struts到现在多框架局面，可以说技术只是一个永不废弃的过度。而技术依赖于项目的整体设计，设计如果存在遗憾或缺点 那么再好的技术也不达到实现目的。
   当然了 项目的设计也是技术 但 单从一点的技术来说 系统的性能优化还远远不够。
包括 设计、软件实现、硬件实现。 不知说的对错哈，不要喷我。

一个系统通常要考虑的不是性能，而是吞吐量和响应时间的均衡。脱离的实际的生产环境去讨论性能，意义不大。性能高并不一定单位时间内完成的笔数就一定多。

   给楼主三个建议做个小小的点评吧。
1. 池化服务器组件：其实按照楼主的意思，更加应该是指容器化（EJB有池，但是Spring似乎没池）。而如果是容器化的话，那么它的目的并不是对性能的优化（如果只是减少对象的产生，工厂就够了）。即使是池，也面临另外一个问题，那就是池对象的泄漏处理（比如讲，一个程序在大循环中从池中获取组件，或者获取组件后并不归还）。对于类似于数据库的连接池来说，因为对象是继承实现同一接口的，那么也就是容易有一个池实现。而对于基于POJO的服务组件来说，去实现这样一个池支持的实现（解决上述泄漏问题）并不容易。
2.  缓存：没错，如果一个企业级系统没有使用缓存或者没有使用好缓存，是绝对不可能获取良好性能的。但是在大型企业系统中，使用缓存又得面临几个问题。第一，如果存在分布式的负载均衡或集群，缓存间的同步；缓存失效的设定，对于业务数据，是需要准确的读写分析，否则的话，缓存算法就成了空谈。也许许多人都认为LRU是最合适的，其实并非如此，许多时候，固定时间失效是常用的。
3.  数据库系统优化：也许每个人都认为它影响了系统的性能，这话并没错。但实际上是大家低估了数据库的处理能力。真正最为常见地影响软件系统性能的是对数据库的访问，而非数据库本身的优化。这种访问包括：比如循环中去读取数据库，比如滥用ORM工具，比如采用非索引查询等等。

    楼主看到的只是影响系统性能的表面，这些问题的原因也许所谓的书中或者忽悠的咨询师口中是经常见的。但真正解决系统性能的优化是无定式的，是需要架构师根据实际情况分析的。

楼主，我也一直追求系统性能的提升，也算是绞尽脑汁。
您现在是什么级别了，项目经理还是架构师了？

呵呵，多谢老哥的点评。我改下第一点的标题。那个第一点我更侧重对无状态线程安全组件的生命周期的管理，容器管理这些组件对性能也是有好处的。我这篇文章的侧重点是如何通过合理的对象建模，然后借助于合理的对业务对象模型的缓存来提升系统性能。

呵呵也许某些企业级的系统，人家也本来更看重数据安全性，完整性，以及项目管理等方面，对性能考虑的不多。性能不好，高性能的服务器，高性能的应用服务器，高性能的数据库服务器顶着。

呵呵，我现在仅仅是一个即将毕业的应届生而已。这些观点也是我对自己项目的一点总结吧。

我感觉 硬件很必要  现在 从技术上把 实现分成多层，大多数应用都集中到单台服务器上，由于 硬件 io 限制，不管是用缓存还是其它技术，也不能突破这些，

应该把分层合理布置到不同的高性能服务器上就能充分利用硬件特性，提高系统性能。