概述

Ø性能优化的思路

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

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

其他补充

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