系统性能(predictable performance)是否可预测之二

在三层架构下，系统的运行环境及技术环境发生了一些变化，具体表现在：

1.      客户端用户数不再可控，任何用户通过浏览器都可以访问现有应用系统。

2.      Oracle数据库网格计算技术日趋成熟，数据库集群的性能和可扩展性大大提高。

3.      在应用服务器层各种应用架构和模型层出不穷，虽然开发效率提高了很多，但系统运行效率不一定能有提高。

在这种情况下，预测系统的性能难度大大加大，毕竟前端客户的并发性不可预测，任何应用系统都会出现各种各样的问题。不过它造就了一大批应用性能管理(APM)的厂商，像Mercury(已被HP收购)，Segue（已被Borland收购），Compuware，IBM和Oracle等传统的数据库中间件厂商也通过并购或者研发的方式参与进来，其主打产品主要是针对应用（特别是三层应用）的性能测试工具,随着技术的发展，APM厂商又提出了业务性能监控的概念，业务性能监控说白一点就是采用哑终端实时模拟一个真实的业务场景，根据定义的一些KPI来判断当前系统的健康状况，一旦发现问题，可以实时报警，并通过其知识库或者其它性能调优工具进行分析，给出可能发生问题的原因，从而可以变被动应对为主动干预，避免发生更严重的事故。

但无论如何监控，系统的效率总是要提高，根据本人的经验，一旦生产系统上线，发现性能问题，再做调优一般效果都不是特别好，即使有一定的性能提高也解决不了根本问题，除非是管理员犯了一些常识性错误，例如操作系统或者数据库、中间件的参数配置不对或者硬件故障。在这种情况下要提高系统的性能一般是变成了提高系统的扩展性，具体表现在：

1.      开发商修改其J2EE应用，一方面从应用层尽量提高端到端的单笔交易效率，例如尽量不用entitybean和stateful sessionbean，另一方面尽量将一些事务处理机制从有状态转变为无状态，从而避免集群当中的状态复制。

2.      在中间件层和数据库层采用集群方式加大处理能力，提高系统的可扩展性。

3.      更新现有硬件设备，增强处理能力。

无论我们怎么优化应用程序，最终系统的瓶颈一般还都是表现在数据访问上，客户端多了，我们可以增加应用服务器的数量，如果不考虑应用服务器的高可用性（high availability and fail over）,甚至都可以不做应用服务器集群，直接通过一个负载均衡器将负载分配到应用服务器即可。但数据库就没有那么容易了，应用服务器层和数据库层最大的区别是应用服务器层没有数据同步的负担，各个应用服务器可以独立工作。即使做了集群，充其量也是一些http session或者stateful sessionbean的同步，其数据量和数据库层需要同步的数据比只能算是小儿科。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16312004/viewspace-476714/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16312004/viewspace-476714/