关于系统性能的思考

根据JE童鞋们的回复，作个总结，提高性能系统的根本：
1. 一个系统通常要考虑的不是性能，而是单位时间内的吞吐量和响应时间的均衡。
2. 技术可以提高性能,池话,负载均衡,分布式都可以提高性能,但是这些都有瓶颈。性能的根本在于业务设计，进行业务的深度分析才能从根本上提高性能。
3. 系统的瓶劲主要集中在数据库的吞吐量。真正最为常见地影响软件系统性能的是对数据库的访问，而非数据库本身的优化。

获益非浅啊，投精华。

我认为影响系统性能的几个因素：
1 memory 慎用池化，有可能造成memory leak。
2 同步   
3 数据库  索引，IO等。

你说的第二段很不错，很有想法，但是这条路是不通的，这句话如何理解，我一点点说给你听：
1.确实是有系统如你所说，几乎每步操做都需要极其严格的事务要求（严格序列化，说的通俗点叫做先后顺序必须要保证），单单说到这其实还是比较好实现的，一般的消息队列都能做到这个效果（脑子里先去除关系数据库的桎梏）。但是有些系统除了严格的序列化，还需要有非常高的实时性要求，假设包括外部因素总延时在5秒之内吧，上交所的股票交易系统就是这样的一个典型例子。

这样的系统不是不能做，但是代价太大，而且做法和通常的做法完全不一样，基本没有什么普遍性可言。他们的做法，说的简单点就是全内存操作，巨大的内存几乎加载了所有必要的实时数据。。。

2.第一个例子过于极端，说说第二种情况，绝大多数的银行吧，为了保证核心系统（实际是记账中心）的交易无差错，基本上所有的操作最终都集中在一台大型机上，跑数据库的（你不要幻想数据库集群能有效的提高性能，那是骗人的）。

3.从第二个例子中的数据库集群骗人事件，引出，如果你仔细看过 J2EE Without EJB的话，我记得好像有这么一句话，最好的分布式就是不要做分布式，感觉有点故弄玄虚，主要意思是这样的，一个通常的分布式集群的系统，其各个节点间的通讯（包括各种同步等的开销）代价往往会把集群带来的性能提升完全抵消掉，而且这样的集群基本没有线性的扩展性，集群的机器数量越多，集群中节点间的通讯的代价就越发恐怖。SNA的思想就是尽可能避免这种依赖于一种集中式集群的瓶颈。我个人还认为，节点间互相关系密切的集群系统的集成测试和运维、升级的复杂度是惊人的高的，成本巨大。

4.我再从另一个角度来说，第一点提到消息队列，恩，当你把一个消息队列的功能做得非常完善，或者说当你把一个缓存系统做得非常完善，例如加上一些类似于数据库的事务控制，那你可能就是在自己造一个分布式数据库了。Memcached DB算是一个这样的典型例子吧。这种缓存系统作为产品拿来用用还是比较靠谱的，自己造，而且要没有什么bug，这代价好像大了点吧。

5.如第四点所说，应该把缓存结构独立出来，单独考虑，例如你要用Memcached服务做缓存服务器，先和原本的J2EE的架构分离出来，JVM本身就是大小限制的，真要用Java做大的缓存框架，其实限制是很多的。所以不要迷信各级缓存，缓存结构不是你想像的那么简单的，不仅仅是开发和设计、调试和部署的成本都非常高。

6.做项目好像人生，不如意十有八九，预算成本和时间成本都是有限的，又要结构简单，又要效果好，往往得从业务出发，简单的例子我前面讲过，例如某些实时性要求不高的查询完全可以放弃实时性，可以用来获取简单的结构，和避开性能瓶颈。而复杂的例子，例如寻找外星人的项目，或者是Google的Map/Reduce，或者是林登实验室的Second Life的分布式计算结构，都是针对特殊的业务设计的。这些都不是传统的编程手段或技术能直接实现的。

7.拓展一下思路吧，第六点提到的简单例子“例如某些实时性要求不高的查询完全可以放弃实时性，可以用来获取简单的结构”，这个例子貌似简单，如果对查询的实时性要求不高，但是查询速度要求很高的话，楼主可以看看数据仓库的概念，不是要楼主学习数据仓库，而是拓展一下思路，思维不要局限在Java或者说JVM上，不要局限在事务型关系数据库存储上。

8.再做个引申，大量的事务型操作其实是很容易造成瓶颈的，但是有时候适当的一些假设，就能够部分的不使用事务，例如假设某张表中没有update和delete操作，只有insert操作，整个业务模块按照这个假设设计就能够很简单的实现，实际上现实世界中的财务流水帐在业务模型上就是这么设计的。。。

9.你有一定的项目经验，一般能根据需求估算出一个系统的各方面的负载有多大，然后再根据以往项目实施的经验，就能比较靠谱的掌握一个性能、成本的平衡点了。

    分析比较到位，看来icewubin还是蛮熟悉性能调优的实质，观点中的2，3，5，6，7，9是蛮认同的，赞一个！

关于第二点 还需要仔细的斟酌,因为把业务弄得数据库要考虑数据库的压力问题.业务放置的位置要么在前台逻辑要么在数据库.放在前台可以减缓数据库压力,放在后台可以提高前台处理能力. 但是有这么一个问题,如果前台有需要进行群集的时候  后台数据库的业务逻辑如何处理. 这时候跑数据库也许就是一个瓶颈了. 总之还是要小心跑数据库这个陷阱,需要很充分的考虑.

这一点我的理解是这样的，银行业务的特点一般是外围系统加核心系统，外围无论如何优化业务，都是要调用核心系统的接口，银行固有的业务特点使得相当一部分业务办理的操作无法做深层次的优化，例如借记卡余额的查询（这种查询操作是不可能做缓存的，对于外围系统来说，每次查询必须要调用核心系统的接口，而不能自说自话的做缓存）。

那么然后说核心系统，暂且不论核心系统是否通过缓存优化一些查询操作，至少目前基本上大部分操作还是依赖于数据库的。我叽叽歪歪说了这些，无非就是举个例子，有这样的场景，无论中间层或外围如何优化，最终对于数据库的压力是固有的，逃不掉的。例如每小时处理10000笔转账业务，这必然带来10000次数据库操作（肯定不止），这是业务特点加上目前的银行核心系统架构带来的固有的数据库的压力。

在这种场景下，因为银行的海量数据，不得不在核心数据库上动脑筋：
1.某人说，数据库做集群不就完了么？Scale Out，可惜几乎不可能，原因复杂一言难尽。

2.一般只能做Scale Up，加CPU，加内存，一般使用大型机，来提高吞吐量。

举这个例子也是想拓宽楼主视野，不同行业，不同业务特点带来的系统瓶颈的位置都不太一样。