Ø性能优化的思路
首先是较为精准的定位问题，借助于相应的工具包，分析系统性能瓶颈在哪，在根据其性能指标，以及所处于层级决定选择优化的方式方法。在选择优化的方式方法时，大家可以参照以下章节调优方法，架构优化递进，进行正确的，有针对性，有步骤的优化。可能会发现部分指导思想或许有相悖嫌疑，大可不必较真，系统优化的过程本身就是一个不断分离+共享的组合拳，至于具体选择哪种优化方式，根据具体需求来定，但大型应用发展的总体思路是不断分离，在通过索引（非数据库）进行关联起来，
切记：优化一定要对系统进行细致的望闻问切，找到性能问题根源切入点，而不被表象迷糊，对症下药，发现病症所在的医生并不比操作手术刀的医生水平差。本文有工具包一章节，对于需要做优化的人员，需要熟悉，他就是我们诊断所用的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切分，降低图片传输的频率和数据量
Ø可以使用静态网页的，避免使用动态网页
架构优化递进