系统性能调优的各个方面

概述

Ø性能优化的思路

首先是较为精准的定位问题，借助于相应的工具包，分析系统性能瓶颈在哪，在根据其性能指标，以及所处于层级决定选择优化的方式方法。在选择优化的方式方法时，你们能够参照如下章节调优方法，架构优化递进，进行正确的，有针对性，有步骤的优化。可能会发现部分指导思想或许有相悖嫌疑，大可没必要较真，系统优化的过程自己就是一个不断分离+共享的组合拳，至于具体选择哪一种优化方式，根据具体需求来定，但大型应用发展的整体思路是不断分离，在经过索引（非数据库）进行关联起来，

切记：优化必定要对系统进行细致的望闻问切，找到性能问题根源切入点，而不被表象迷糊，对症下药，发现病症所在的医生并不比操做手术刀的医生水平差。本文有工具包一章节，对于须要作优化的人员，须要熟悉，他就是咱们诊断所用的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，压力测试，发现性能瓶颈

其余补充

本文任何一处都可展开叙述，并辅以案例，但时间关系，但愿工程中心有人帮忙完善或者之后有时间本身完善吧