系统性能优化的心的.docVIP

系统性能优化的心的 最近在找工作的时候，参加了一些面试（都是架构啊，项目经理之类的岗位），面试官的问题都会涉及到“大数据量的系统性能优化”，自己根据自己的经验简单阐述了些，今天回忆了下，感觉回答的不是很好，虽然曾经解决过很多类似问题。今天我总结下，大家交流下。 我是走jee路线的，涉及的项目结构大致如下： 不同之处就是使用的应用服务器，中间件的区别，我们这里将定应用服务，中间件的配置管理，以及架构的涉及和编码的实现都是在没有问题的环境下，系统出现了性能的瓶颈，常见的现象如下： 客户点击一个按钮，要经过几分钟，几十分钟，甚至几小时（视不同的操作而定），才能看到预期的效果或者干脆没有结果（一直等待）或者直接去错误提示页面了。总之就是客户根本无法接受的响应速度。 出现上述情况对客户来说是致命的，一般都会坚决要求开发人员或维护人员给予快速解决。这类问题的出现会严重影响客户对企业的技术能力的信任，尤其是当今信息化高速发展，各行业对IT有足够的认识的环境下。 要解决问题，必须快速定位问题的根源，依据我的经验，问题一般出现在如下几个地方： 1 客户端与服务的通讯过程 传递数据量大或解析传递的数据效率低（比如：WebService架构) , 一般通过压缩数据，更换解析数据工具或跟换数据传递方式可以解决问题。 Web服务器出现大量并发，导致服务器运行压力，这种情况一般要弄清楚并发的原因。访问量巨大，达到服务器处理阀值，一般可以通过如下手段解决： 静动态页面分离或缓存静态 Web服务器集群 硬件调整 由于业务处理缓慢，导致并发量大。这种情况是最为常见的。要解决这类问题 必须保证业务实现是快速执行的。业务逻辑的处理一般都是很长快速的，多数 问题都出现业务逻辑和数据库的交互上，具体的方式下面介绍。 2 持久层与数据库的通讯过程 数据库驱动程序效率低下，更换响应的驱动程序或者直接使用数据库api来解决。 操作数据库时，传递的数据量过大，这种情况一般重新审视需求，更换处理方式来解决。比较常见的分页查询等 3 数据库的内部运行 这里是多数问题的根源，尤其是数据量巨大的情况下。多数的问题都是基础数据表大数据量的情况。由于商业系统大部分操作都会映射成对数据库的检索操作，主要体现就是如果快速从大数据量的基础表获取期望数据就成了解决该类的问题的根本。 一般按两种情况来分别解决： （1） 基础表存储的数据量在数据库管理系统的承受范围内 这类情况一般从两个角度去解决 A 使用索引 对于索引的使用开发人员都不陌生了，但正确使用索引还真不是件容易的事，我们先来看下常见的索引，弄清楚索引的机制再使用，是很有必要的，至少俺是这么认为的。 常用索引分为1 聚集索引以最快的速度缩小查询范围以最快的速度进行字段排序。 最频繁使用的、用以缩小查询范围的字段上需要排序的字段上 在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致一般情况下如果能用关联查询就不用子查询 把大数据量的基础表拆分成若干个数据量较小的表，这样检索的基础数据就少了。同样的方法也可以用在索引上，即：把索引表拆分成较小的若干个索引表。各数据库厂商都提供了“表分区”的方法来支持此类操作。分区多的情况下，可以创建数据字典来管理表分区。具体的表分区操作，这里就不说了。如果数据量大刀分区后仍然过大，就 要从硬件上来解决了。比如： 数据库服务器集群 增加或更换存储设备 仔细分析所有的性能问题，你会发现都是可以预防的，也就是说性能问题应该事先考虑，而不是等出现问题再去解决。一般应该从如下几方面着手： 需求阶段，明确数据存储容量【数据量大小】及数据分布规律（大数据表是谁）。 设计阶段，确定好表分区，索引；测试疑似压力交易并针对处理。 编码阶段，根据数据及业务特征编写最优sql语句（测试考证）。 测试过程，严格验证性能敏感交易。 1 大数据量 小数据量 小数据量 小数据量 小数据量 ......................