2022年系统性能调优 .pdf

《2022年系统性能调优 .pdf》由会员分享，可在线阅读，更多相关《2022年系统性能调优 .pdf（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、医生并不比操作手术刀的医生水平差。 本文有工具包一章节， 对于需要做优化的人员，需要熟悉，他就是我们诊断所用的CT ，例如我们发现内存高了，首先想到不是内存不够用，而是为什么如此消耗内存，用工具看看内存消耗在什么地方，试想之，如在医院，病人告诉医生，他心脏不好，医生就换心脏，那样的话，每个人只要熟练掌握菜刀，都可以做医生迭代优化名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 8 页 - - - - - - - - - 性能优化未必一次性就能满足的，可能此处瓶颈消失了，系统

3、一旦运转快速后， 在其他地方又发现新的性能瓶颈，所以性能优化是一个迭代的工作。直至满足系统需要的性能指标。优化的成本系统性能设计或优化是否可以一步升天，按照最好的分布式架构进行设计和优化呢， 单个节点一直也运转及其健康，理论上是可以达到共产国际的， 但实际实施层面不可取， 必须结合实际的非功能需求进行设计和优化， 一则一步到极致的话， 系统的成本太过虑庞大，光是性能设计和优化的成本就高于系统本身给客户所提供的价值，也造成研发成本开销过大。 二则好像能够架构这样完美系统的人还没诞生。所以一句话也同样适合架构师：有理想而不理想化，废话少扯：具体见法则调优方法数据库优化很多应用，优化DB 往往是最直

4、接，最方便，见效最显著的，但并非所有的系统性能都处在瓶颈，或者DB 瓶颈解决之后，可能应用层瓶颈，WEB层瓶颈，甚至架构瓶颈都会冒出来了 ,所以数据库优化十分重要，但往往很多人理解系统优化就是数据库优化，是不全面的。优化角色一般推荐具备较深数据知识的程序员，或者专业的DBA,而不只是会CRUD开名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 8 页 - - - - - - - - - 发人员建立正确的主键，外键，以及索引分离原则：读写分离，业务数据分离a) 分库b) 分区

5、c) 分表d) 分列（将大字段，不常用的隔离到他表，按需查询）选择隔离级别： 某些对数据一致性要求不高的，可以牺牲部分一致性，降低加锁阻塞保证事务简短以及减少不必要的锁机制。查询优化规则：e) 避免表内的相关子查询；f)避免排序或为尽可能少的行排序，g) 做大量数据排序时相关数据放在临时表中h) .尽量在 where 后多传查询条件，以减少不必要返回的行i).尽量 select只需要的字段 ,以减少不必要返回的列分页存储过程： 大列表的查询也可以利用分页存储过程达到优化效果。利用数据库缓存，视图，临时表等最大程度优化系统，并对存储过程和函数进行必要的优化如有需要，可以冗余表中字段，避免联合查询

6、如有需要， 也可以将表内的大字段分离到单独表中，使其名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 8 页 - - - - - - - - - 单独查询必做多表关联时， 尽量过滤不符条件表中数据，减少笛卡尔积计算量复杂表表：如实时性要求不高，尽量后台任务计算，避免动态查询应用层优化应用层优化侧重于应用层本身的逻辑优化，算法优化， 代码优化等，优化的角色可以是熟悉应用的程序员优化算法，选择合适高效的算法，降低不必要的递归，循环、多层循环嵌套等计算避免申请过多的不必要的内存开

7、销降低内存泄露（using，Dispose，弱引用， Finalize）使用频率较低的大文件，大对象，大数组等使用完毕后，及时释放使用频率较高的大文件，大对象，大数组尽量缓存考虑多线程技术选择适当的通信方式： 长连接，短连接 ,有以下方式Socket、Remoting、Web Services(Rest,Soap) 、WCF、 Named Pipes 降低应用之间通信次数，例用户认证服务，工作流服务，数据库服务降低应用之间传输数据量，不必要传输的不传，少传名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - -

8、- - - - 第 4 页，共 8 页 - - - - - - - - - 缓存机制：缓存常用的，不易变化的，偶有变化，可以考虑缓存依赖机制支持异步计算，降低等待时间考虑延迟加载，或者提前加载两种方式分离原则： 分离业务模块 ,如分离大 I/O 模块、分离高耗内存模块，分离高耗宽带模块考虑分布式应用， 分布式存储， 如以上所有仍然搞不定的Web 优化Web 优化偏向于熟悉前端开发的技术人员减少 http 请求避免 404 错误在 html 页面 header 加入缓存标签Gzip 压缩网页减少 cookie 体积使用外部的js 和 css 消减 js 和 css 压缩 js 使用 css sp

9、rites 技术，众多图片合成在一起，通过CSS切分，降低图片传输的频率和数据量可以使用静态网页的，避免使用动态网页名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 8 页 - - - - - - - - - 架构优化递进为以示与应用层优化的区别，本文对架构的描述更侧重偏向于物理层面，再次赘述下，涉及变更架构的，需要我们的应用具有良好的拓展性，考验我们的架构师平时的功底，如何刚刚好满足需求以及两三年内业务增量，但并非架构做的越强大，越灵活，越可配置，越易水平拓展就是越好的，

10、其一考虑此应用的投入产出比，换言之，是否值得投入这么多架构设计成本，其二架构设计也是具有一定的时效性的，IT速度太快了，今天的好东西未必是明天的好东西，年轻貌美的姑娘，总有变成老太婆那一天嘛,再者、越灵活的架构，就意味着存在更多的配置项，从某一方面，反而增加了系统的复杂度，最后、很多大型，成熟的应用，也并非一蹴而就，而是通过不断的调整优化，不断变更架构的。圣人也并非天生的，而是不断的总结，提炼，优化，重构硬件方面使用高性能的小型机、存储设备。 使用极好的网络带宽物理分离 Web Server 和 DB Server或者其他服务如：用户认证服务缓存数据缓存机制名师资料总结 - - -精品资料欢迎

11、下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 8 页 - - - - - - - - - 页面缓存机制物理分离业务模块，单业务单独部署一台服务器部署多台 Web Server Web 负载均衡 -F5 数据读写分离使用消息队列进行各种应用间进行同步/异步计算应用间选择合适的通信方式，通信协议Web 分布式，应用分布式，数据分布式分布式的节点使用高性能服务器，小型机群,辅以高速网络带宽等工具包进程管理器， CPU，内存， I/O 日志： IIS日志， Windows 日志，系统本身日志使用 dotTrace

12、,跟踪方法执行时间，找出速度慢的方法，针对性优化Sql Profile 跟踪 SQL耗时情况，针对性优化HttpWatch 跟踪请求耗时，以及发送和收到数据量Performance Count，使用计数器，统计相关性能指标CLRProfiler内存泄露检测工具LoadRunner，压力测试，发现性能瓶颈名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 8 页 - - - - - - - - - 其他补充本文任何一处均可展开叙述，并辅以案例，但时间关系，希望工程中心有人帮忙完善或者以后有时间自己完善吧名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 8 页 - - - - - - - - -