Ø 性能优化的思路

首先是较为精准的定位问题借助于相应的工具包分析系统性能瓶颈在哪在根据其性能指标以及所处于层级决定选择优化的方式方法。在选择优化的方式方法时大家可以参照以下章节调优方法架构优化递进进行正确的有针对性有步骤的优化。可能会发现部分指导思想或许有相悖嫌疑大可不必较真系统优化的过程本身就是一个不断分离共享的组合拳至于具体选择哪种优化方式根据具体需求来定但大型应用发展的总体思路是不断分离在通过索引非数据库进行关联起来切记优化一定要对系统进行细致的望闻问切找到性能问题根源切入点而不被表象迷糊对症下药发现病症所在的医生并不比操作手术刀的医生水平差。本文有工具包一章节对于需要做优化的人员需要熟悉他就是我们诊断所用的CT例如我们发现内存高了首先想到不是内存不够用而是为什么如此消耗内存用工具看看内存消耗在什么地方试想之如在医院病人告诉医生他心脏不好医生就换心脏那样的话每个人只要熟练掌握菜刀都可以做医生Ø迭代优化性能优化未必一次性就能满足的可能此处瓶颈消失了系统一旦运转快速后在其他地方又发现新的性能瓶颈所以性能优化是一个迭代的工作。直至满足系统需要的性能指标。Ø优化的成本系统性能设计或优化是否可以一步升天按照最好的分布式架构进行设计和优化呢单个节点一直也运转及其健康理论上是可以达到共产国际的但实际实施层面不可取必须结合实际的非功能需求进行设计和优化一则一步到极致的话系统的成本太过虑庞大光是性能设计和优化的成本就高于系统本身给客户所提供的价值也造成研发成本开销过大。二则好像能够架构这样完美系统的人还没诞生。所以一句话也同样适合架构师有理想而不理想化废话少扯具体见法则调优方法数据库优化很多应用优化DB往往是最直接最方便见效最显著的但并非所有的系统性能都处在瓶颈或者DB瓶颈解决之后可能应用层瓶颈WEB层瓶颈甚至架构瓶颈都会冒出来了,所以数据库优化十分重要但往往很多人理解系统优化就是数据库优化是不全面的。优化角色一般推荐具备较深数据知识的程序员或者专业的DBA,而不只是会CRUD开发人员Ø 建立正确的主键外键以及索引Ø 分离原则读写分离业务数据分离a) 分库b) 分区c) 分表d) 分列将大字段不常用的隔离到他表按需查询Ø 选择隔离级别某些对数据一致性要求不高的可以牺牲部分一致性降低加锁阻塞Ø 保证事务简短以及减少不必要的锁机制。Ø 查询优化规则e) 避免表内的相关子查询f) 避免排序或为尽可能少的行排序g) 做大量数据排序时相关数据放在临时表中h) .尽量在where后多传查询条件以减少不必要返回的行i) .尽量select只需要的字段,以减少不必要返回的列Ø 分页存储过程大列表的查询也可以利用分页存储过程达到优化效果。Ø 利用数据库缓存视图临时表等最大程度优化系统并对存储过程和函数进行必要的优化Ø 如有需要可以冗余表中字段避免联合查询Ø 如有需要也可以将表内的大字段分离到单独表中使其单独查询Ø 必做多表关联时尽量过滤不符条件表中数据减少笛卡尔积计算量Ø 复杂表表如实时性要求不高尽量后台任务计算避免动态查询应用层优化应用层优化侧重于应用层本身的逻辑优化算法优化代码优化等优化的角色可以是熟悉应用的程序员Ø 优化算法选择合适高效的算法降低不必要的递归循环、多层循环嵌套等计算Ø 避免申请过多的不必要的内存开销Ø 降低内存泄露usingDispose弱引用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压力测试发现性能瓶颈其他补充