浅谈改进应用系统性能常用策略.docVIP

浅谈改进应用系统性能常用策略 　　 摘 要：本文主要简述了改进应用系统性能的常用策略，并从系统层次架构角度分别介绍了在不同领域所采用的方法，本文的侧重点放在解决问题的方法论上，期待能够达到抛砖引玉之效。 　　笔者在金融系统从事软件开发工作，目前在金融领域的绝大多数应用系统，包括储蓄、会计、信贷、财务、国际业务、网上银行等业务系统以及OA、1104、反洗钱、经营决策等低柜管理系统，均采用分布式三层技术架构，即持久层、业务逻辑层和展示层，对性能的持续改进是系统推广后是不得不面对的问题，下面我从应用系统的三层架构方面浅谈改进系统的性能的一些方法。 　　关键词：改进；应用系统；性能；常用策略 　　 　　一、问题的提出 　　 　　做过软件项目的人都深有体会，经过辛辛苦苦的需求、设计、开发、测试、部署上线等系列工作，还没来得及松口气就要不断接听接踵而至的用户电话，面对大量用户访问、高并发请求，技术人员最郁闷的事莫过于心爱的系统响应缓慢甚至宕机，这不仅会造成业务的延误，领导的问责，而且先天的心理自豪感也会荡然无存，面对表现不佳的分布式系统：是用户操作问题，应用程序问题，还是数据库问题？应该从何处进行改进？ 　　在客观环境以及主观形式下，有人会在三层架构中根据经验斗胆选择一层作出推测，不再继续从浩繁的代码寻找错误或者低效率的算法，或者放弃彻底搜寻SQL语句和数据库表的做法。但遗憾的是，这种解决问题的方式经常是过度简化的，因为系统前端展示、应用程序、数据库都不是在孤立地运转。对系统性能的改进需要一种综合解决方法，应该提高对这个相互联系的系统内所有三个部分的能见度：数据库操作的执行效率、应用程序架构以及资源的利用和配置，还包括基本的硬件基础设施性能。 　　 　　二、解决方案 　　 　　在改进应用系统性能的解决方案中，首先让人想到的集中在这样几个环节：使用更高性能的服务器（或者为服务器增配）、更高性能的数据库、还有更高性能的容器中间件等等。如此解决思路并非不可，但也是最容易的，同时在一定程度上还意味着更大的资金投入和更难的决策层支持，并且这样的方案具备瓶颈，没有很好的扩展性，无法从根本上解决系统面临的高负载和高并发问题。笔者认为需从以下几个方面对系统进行综合治理。 　　（一）持久层面 　　该层在具体实现上一般表现为某一类数据库，其性能的改进主要体现在逻辑设计、物理设计和运行管理上。 　　1、数据库的逻辑设计结果不是唯一的，为提高基于数据库的应用系统的性能，通常以规范化理论为指导，适当地修改、调整数据模型的结构，称之为数据模型优化，要求数据模型达到第三范式以上。笔者曾经见到一个数据库设计采用自增1的sequences作为表的主键，非常值得商榷。 　　2、数据库物理设计需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，结果会产生多种方案，必须对此进行细致评价，选择一个较优的方案作为数据库的物理结构。例如，存放n年业务数据的物理表，随着时间的增加会达到千百甚至上亿数据量级的记录，对于复杂查询几乎就是一种灾难，此时应该采用数据库分区技术，能够成倍提高系统的响应速度。 　　3、数据库的运行管理主要通过对数据库的参数进行调整来达到改进性能的目的。在决定进行系统性能调优级时，首先应制定一个完善的调优级方案，先监控系统并分析问题所在，然后根据分析结果每次调整一个参数，再进一步监控系统查看系统性能有无变化，然后做进一步调节。其中有一个重要的原则：每次最好只调节一个参数。 　　数据库性能通常与磁盘I/O、CPU、共享内存和网络4个方面有关，孰轻孰重，要根据整个系统的实际情况具体分析。 　　（二）业务逻辑层面 　　该层实现了应用系统的主要业务逻辑，包含典型的应用程序、关键技术以及支撑整个系统运转的应用服务器等硬件设备，其性能的改进主要体现在下述几个方面。 　　1、应用程序 　　应用程序的优化通常可分为两个方面：源代码优化和SQL语句优化，前者可以采取更高效率的算法、增加并发处理能力以及及时回收空闲资源等等，除了一些程序BUG必须进行调整外，源代码优化很大程度在时间成本和风险控制上代价很高；后者，一个好的SQL往往可以使系统的性能提高数十倍，那种认为SQL优化是DBMS的任务，与程序中的SQL语句关系不大的想法是错误的！尽管现在数据库产品在SQL优化方面做得越来越好，但很难设想一个原本糟糕的SQL经过系统优化后会变得高效，因此SQL语句的优劣至关重要，优化SQL的建议如下： 　　（1）合理使用索引：where子句中的变量顺序应与索引键顺序相同。 　　（2）将最具有限制性的条件放在前面，大值在前，小值在后。 　　（3）尽量避免采用matches或like通配符匹配查询。 　　（4）尽量避免相关子查询，嵌套层次越多