注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

天涯倦客的博客

祝福你朋友永远快乐!

 
 
 

日志

 
 

转载:系统性能调优吐血总结分享:原创  

2011-07-25 10:04:53|  分类: asp.net |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

概述

? 性能优化的思路

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

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

其他补充

系统性能调优
  评论这张
 
阅读(406)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017