性能设计：要响应还是要吞吐量

   衡量系统性能有俩个指标，分别是响应和吞吐量。通常企业应用系统更看重的是吞吐量，即能否支持更多的用户访问，或者能处理更多的报文。记得JDK Concurrent API的一个主要设计目的就是可扩展性-在单CPU的情况下，性能不及synchronized.耗费的资源多于synchronized（创建了很多对 象，但synchronzied可用任何对象作为锁）。但在多CPU或者其他更多的资源下，JDK Concurrent API 能充分利用CPU资源，从而使你的应用有较大的吞吐量。譬如，Hashtable 读写都会锁，而ConcurretnHashMap在读的时候就不会，自然会提高吞吐量。

   响应和吞吐量有时候并不能同时获得，譬如，为了提高响应，你可以做一个Cache，如果你的Cache只是JVM内的话，那要是进行集群以提高吞吐量，那 么你的Cache就有问题了。所以性能设计，一定要考虑到响应和吞吐量这来个因素。

   上面说了，企业应用更看重吞吐量。那如何设计一个高吞吐量的系统了。我觉得主要是俩个方法。

    一是系统是否支持扩展：如果系统实在是提高不了，我能否增加硬件来提高？ 这种方式又通常有三种做法。

    1 增加主机CPU,内存，更换更好的磁盘.系统不需要改变

    2 增加新的主机，这也叫集群。 这种方式能极大的增加吞吐量，但扩展性还是有限。而且系统需要根据集群做特定的设计

   3 增加新的主机，水平扩展。特定的业务，访问特定的系统。就好比门户网站新闻，社会生活的访问一台好机器，而冷僻的健康类访问令一台机器。这应该是种终极的 扩展方式。再比如短信查询业务通过平台派发到4，5台机器里，而缴费请求少，可以派发到1，2台机器上。当然，最通常的情况是随机派发

      水平扩展难点不同于集群，不用关心如何实现，水平扩展需要在系统最初设计的时候就要考虑。搞不好可能实现不了。涉及到到用户会话以及流程的需求，都需要仔 细考虑，因为请求和响应数据可能在流程中位于不通的主机。对于简单会话来讲，可以在cookie中保存特定的信息，但对于复杂的流程，一次会话有多个请求 和响应，如何进行水平扩展，则很麻烦。

     上面的方法都很粗，如果系统实现了集群或者水平扩展，则即使系统设计的很差，那也能满足要求，要客户多掏钱升级硬件或者多买机器就是了（也碰到过系统实在 有问题，16个CPU，在压力测试下只用到了俩个，这样就没有办法扩展）

    另外增加吞吐量的方法就是对应用精益求精了 ，小到用ConcurentHashMap代替 Map,Stringbuilder代替StringBuffer，大到用Cache,优化JDBC ，SQL等等了。总之，少用系统资源，又能充分利用系统资源，这就是个好系统，不过这涉及到设计和编码，还是有（管理）难度的，客户，项目经理，甚至是架 构师其实都不看重这个方法，因为完成好太累，还不如集群或者水平扩展