架构师的思考:性能优化到何处为止？选择的原则

人生三苦：选择，后悔，绝望.为了避免后两项，所以才绞尽脑汁去做出明智的选择。人人都无时无刻不面临选择．做软件开发的，从初级，到中级，到高级，所掌握的知识和技术越来越多，面临的选项越来越多，对选择进行评估也越来越困难和复杂，一项选择所造成的影响也越来越大．所以，做软件做到架构师，就是和人生三苦之一的＂选择＂整天打交道的职业．

 

对于互联网应用网站架构师而言，性能优化是他工作的重中之中。可以这么说，如果不需要考虑性能优化，特别是在经费，人力和时间限制下进行性能优化，那么，在互联网应用软件开发中所遇到的许多问题都不是问题。性能优化到何处为止，采用什么方案，是架构师经常面对的选择之一．如果性能优化不够，那么，网站无法应对用户负载，用户会因为系统反应速度慢而流失，整个项目都可能失败．再者，如果在性能出现问题后再去优化，那么就会面临许多重复工作和软件修改问题，系统越大，修改的工作量也越大．另一方面，也有可能过度追求性能优化，从而造成项目复杂度和开发工作量增大，使得项目完工时间延迟，造成商机贻误的问题．所以，为了帮助架构师做出正确的选择，应当有一些基本原则．

 

要为决定性能优化到何处为止定下指导原则，就必须对架构师进行性能优化的招数进行分析和分类，只有这样，才能确定这些原则．通常，架构师进行性能优化的招数可以分为简单招数和复杂招数，简单招数包括，索引，算法，查询优化，缓存，合并数据访问调用从而减少对数据库的访问次数，等等，这些招数，通常会花费不多，又足够有效，关于查询优化所能产生的性能优化程度，可以参看＂深度优化sql查询, 提升性能一百倍是什么概念? ＂http://www.cnblogs.com/kakrat/archive/2010/12/29/1921125.html. 复杂招数呢？有表的垂直分割和水平分割（data partition），数据replication，transaction management优化，使用批处理和代理来代替在线实时处理，等等．所有这些复杂招数都会一定程度的增加软件开发的复杂度，增加工作量．

 

为什么说这些复杂招数会增加工作量呢．举例来说吧，transaction management优化．在这方面，可做的优化有，使用inline sql transaction，而不是client side transaction，使用auto commit transaction 模式，缩短由于跨语句transaction而造成的transacton lock延时，但是，这时，你就必须考虑到出现异常时transaction不完整而造成的数据不一致给系统造成的影响,这可能会导致编程复杂化。这种做法，在实现一些非关键业务（比如不涉及到金钱等）时也是一种选项。此外，对于分布式的transaction管理，有现成的系统性的方法，比如微软的distributed transaction coordinator(dtc)，使用起来也相当的简单方便．但是，dtc因为是通用的解决方案,所以它不可能进行很多优化, dtc通常会使得性能下降一倍左右，如果要处理特别巨大的用户负载，连这方面也可以进行优化，那就是不用这些通用的现成的解决方法，而是根据具体问题设计专门的方法，如果使用专门定制的transaction管理方法，还可以把性能提高50%左右，对于大系统，这也是很可观的提升和节省．

 

有了对这些招数的分类，那么再根据项目的经费，人力和时间要求的情况，就可以比较容易做出选择了．简单的优化招数，应当尽量的使用，不会造成工作量的过多增加。复杂的优化方法，在经费人力时间紧张时，如果不是涉及最基本的数据，最常用的功能，应当尽量避免。