系统性能调优吐血总结经验分享

开发 前端
系统性能设计或优化是否可以一步升天,按照最好的分布式架构进行设计和优化呢,单个节点一直也运转及其健康,理论上是可以达到共产国际的,但实际实施层面不可取,必须结合实际的非功能需求进行设计和优化.

性能优化的思路

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

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

其他补充

 

系统性能调优

 

源文档下载:http://down.51cto.com/data/220108

【编辑推荐】

  1. 简单介绍Asp.net网站的性能优化
  2. 介绍索引访问方法及索引优化
  3. ASP.NET网站性能优化 需要考虑哪些方面
  4. 整合、协作与优化 让软件开发成为团队行为
  5. 一个超棒的CSS小工具:最佳Web性能优化
责任编辑:陈贻新 来源: 围成的博客
相关推荐

2011-03-10 14:40:54

LAMPMysql

2013-02-28 13:37:59

系统性能调优技术实战

2010-09-26 13:48:51

JVM调优

2011-03-18 11:21:48

2013-03-20 17:18:07

Linux系统性能调优

2011-03-18 11:13:07

LAMP度量性能

2011-03-21 09:35:38

LAMP调优网络文件

2011-03-10 14:40:52

2013-03-12 17:33:17

Linux系统性能调优

2021-07-15 08:00:47

系统性能调优cpunuma架构

2011-03-21 09:17:35

LAMP调优磁盘

2017-07-04 13:02:02

Linux系统性能调优工具

2011-03-10 14:40:50

2011-03-18 11:00:48

LAMPLAMP 架构

2013-03-18 15:35:30

2011-05-27 10:35:05

PerfLinux系统性能

2013-03-18 15:07:10

Linux系统性能调优

2019-09-17 08:56:29

TomcatJVM性能

2012-01-10 14:35:08

JavaJVM

2017-07-21 08:55:13

TomcatJVM容器
点赞
收藏

51CTO技术栈公众号