概述
Ø 性能优化的思路
首先是较为精准的定位问题,借助于相应的工具包,分析系统性能瓶颈在哪,在根据其性能指标,以及所处于层级决定选择优化的方式方法。在选择优化的方式方法时,大家可以参照以下章节调优方法,架构优化递进,进行正确的,有针对性,有步骤的优化。可能会发现部分指导思想或许有相悖嫌疑,大可不必较真,系统优化的过程本身就是一个不断分离+共享的组合拳,至于具体选择哪种优化方式,根据具体需求来定,但大型应用发展的总体思路是不断分离,在通过索引(非数据库)进行关联起来,
切记:优化一定要对系统进行细致的望闻问切,找到性能问题根源切入点,而不被表象迷糊,对症下药,发现病症所在的医生并不比操作手术刀的医生水平差。本文有工具包一章节,对于需要做优化的人员,需要熟悉,他就是我们诊断所用的CT,例如我们发现内存高了,首先想到不是内存不够用,而是为什么如此消耗内存,用工具看看内存消耗在什么地方,试想之,如在医院,病人告诉医生,他心脏不好,医生就换心脏,那样的话,每个人只要熟练掌握菜刀,都可以做医生
Ø 迭代优化
性能优化未必一次性就能满足的,可能此处瓶颈消失了,系统一旦运转快速后,在其他地方又发现新的性能瓶颈,所以性能优化是一个迭代的工作。直至满足系统需要的性能指标。
Ø 优化的成本
系统性能设计或优化是否可以一步升天,按照最好的分布式架构进行设计和优化呢,单个节点一直也运转及其健康,理论上是可以达到共产国际的,但实际实施层面不可取,必须结合实际的非功能需求进行设计和优化,一则一步到极致的话,系统的成本太过虑庞大,光是性能设计和优化的成本就高于系统本身给客户所提供的价值,也造成研发成本开销过大。二则好像能够架构这样完美系统的人还没诞生。所以一句话也同样适合架构师:有理想而不理想化,废话少扯:具体见法则
调优方法
数据库优化
很多应用,优化DB往往是最直接,最方便,见效最显著的,但并非所有的系统性能都处在瓶颈,或者DB瓶颈解决之后,可能应用层瓶颈,WEB层瓶颈,甚至架构瓶颈都会冒出来了,所以数据库优化十分重要,但往往很多人理解系统优化就是数据库优化,是不全面的。优化角色一般推荐具备较深数据知识的程序员,或者专业的DBA,而不只是会CRUD开发人员
Ø 建立正确的主键,外键,以及索引
Ø 分离原则:读写分离,业务数据分离
a) 分库
b) 分区
c) 分表
d) 分列(将大字段,不常用的隔离到他表,按需查询)
Ø 选择隔离级别:某些对数据一致性要求不高的,可以牺牲部分一致性,降低加锁阻塞
Ø 保证事务简短以及减少不必要的锁机制。
Ø 查询优化规则:
e) 避免表内的相关子查询;
f) 避免排序或为尽可能少的行排序,
g) 做大量数据排序时相关数据放在临时表中
h) .尽量在where后多传查询条件,以减少不必要返回的行
i) .尽量select只需要的字段,以减少不必要返回的列
Ø 分页存储过程:大列表的查询也可以利用分页存储过程达到优化效果。
Ø 利用数据库缓存,视图,临时表等最大程度优化系统,并对存储过程和函数进行必要的优化
Ø 如有需要,可以冗余表中字段,避免联合查询
Ø 如有需要,也可以将表内的大字段分离到单独表中,使其单独查询
Ø 必做多表关联时,尽量过滤不符条件表中数据,减少笛卡尔积计算量
Ø 复杂表表:如实时性要求不高,尽量后台任务计算,避免动态查询
应用层优化
应用层优化侧重于应用层本身的逻辑优化,算法优化,代码优化等,优化的角色可以是熟悉应用的程序员
Ø 优化算法,选择合适高效的算法,降低不必要的递归,循环、多层循环嵌套等计算
Ø 避免申请过多的不必要的内存开销
Ø 降低内存泄露(using,Dispose,弱引用,Finalize)
Ø 使用频率较低的大文件,大对象,大数组等使用完毕后,及时释放
Ø 使用频率较高的大文件,大对象,大数组尽量缓存
Ø 考虑多线程技术
Ø 选择适当的通信方式:长连接,短连接,有以下方式Socket、Remoting、Web Services(Rest,Soap)、WCF、 Named Pipes
Ø 降低应用之间通信次数,例用户认证服务,工作流服务,数据库服务
Ø 降低应用之间传输数据量,不必要传输的不传,少传
Ø 缓存机制:缓存常用的,不易变化的,偶有变化,可以考虑缓存依赖机制
Ø 支持异步计算,降低等待时间
Ø 考虑延迟加载,或者提前加载两种方式
Ø 分离原则:分离业务模块,如分离大I/O模块、分离高耗内存模块,分离高耗宽带模块
Ø 考虑分布式应用,分布式存储,如以上所有仍然搞不定的
Web优化
Web优化偏向于熟悉前端开发的技术人员
Ø 减少http请求
Ø 避免404错误
Ø 在html页面header加入缓存标签
Ø Gzip压缩网页
Ø 减少cookie体积
Ø 使用外部的js和css
Ø 消减js和css
Ø 压缩js
Ø 使用css sprites技术,众多图片合成在一起,通过CSS切分,降低图片传输的频率和数据量
Ø 可以使用静态网页的,避免使用动态网页
架构优化递进
为以示与应用层优化的区别,本文对架构的描述更侧重偏向于物理层面,再次赘述下,涉及变更架构的,需要我们的应用具有良好的拓展性,考验我们的架构师平时的功底,如何刚刚好满足需求以及两三年内业务增量,但并非架构做的越强大,越灵活,越可配置,越易水平拓展就是越好的,其一考虑此应用的投入产出比,换言之,是否值得投入这么多架构设计成本,其二架构设计也是具有一定的时效性的,IT速度太快了,今天的好东西未必是明天的好东西,年轻貌美的姑娘,总有变成老太婆那一天嘛,再者、越灵活的架构,就意味着存在更多的配置项,从某一方面,反而增加了系统的复杂度,最后、很多大型,成熟的应用,也并非一蹴而就,而是通过不断的调整优化,不断变更架构的。圣人也并非天生的,而是不断的总结,提炼,优化,重构
Ø 硬件方面使用高性能的小型机、存储设备。使用极好的网络带宽
Ø 物理分离Web Server和DB Server或者其他服务如:用户认证服务
Ø 缓存
ü 数据缓存机制
ü 页面缓存机制
Ø 物理分离业务模块,单业务单独部署一台服务器
Ø 部署多台Web Server
Ø Web负载均衡-F5
Ø 数据读写分离
Ø 使用消息队列 进行各种应用间进行同步/异步计算
Ø 应用间选择合适的通信方式,通信协议
Ø Web分布式,应用分布式,数据分布式
Ø 分布式的节点使用高性能服务器,小型机群,辅以高速网络带宽等
工具包
Ø 进程管理器,CPU,内存,I/O
Ø 日志:IIS日志,Windows日志,系统本身日志
Ø 使用dotTrace,跟踪方法执行时间,找出速度慢的方法,针对性优化
Ø Sql Profile跟踪SQL耗时情况,针对性优化
Ø HttpWatch跟踪请求耗时,以及发送和收到数据量
Ø Performance Count,使用计数器,统计相关性能指标
Ø CLRProfiler内存泄露检测工具
Ø LoadRunner,压力测试,发现性能瓶颈
其他补充
![系统性能调优 系统性能调优](https://images.cnblogs.com/cnblogs_com/wcyao/201106/201106291308422015.png)