• 服务器性能剖析


    1 概述

         程序运行在服务器上,通过使用服务器的各种资源完成设定的各种任务。我们常常会遇到,网页一直在转圈、页面假死等情况,这些现象被用户认为程序很慢、性能很差。那什么是性能?如何衡量性能?

    性能performance即表现,具体来说就是运行在服务器上的程序的运行效率。体现到用户层面的就是等待时间。所以可以简单理解性能为执行某件任务所花费的时间,一般使用响应时间RT(Reponse Time)描述。更具体的定位到基于数据库的应用或数据库服务器上,性能通过查询的响应时间来衡量

         当然,对于性能衡量,还有其他指标,比如CPU利用率、吞吐量等,有些人一看到机器CPU利用率上升,就会认为程序性能不优,但是仔细想想,CPU不就是来使用的吗,难道CPU利用率一直保持低位就很好?CPU利用率升高,说明运行的程序对资源的利用率提升了,随后也可能会带来响应时间的降低。还有吞吐量(Throughtoutput),这个指标其实和RT殊途同归,吞吐量定义为单位时间内的任务执行数量,吞吐量高代表单位时间内执行的任务数量变多,同样执行每个任务所花费的时间也就变少了。

         所以通常所说的性能优化,很大一部分都是做在一定的工作负载下的尽可能地降低任务执行时间,即降低响应时间。那如何降低响应时间?首先要知道时间花在哪,比如一个查询RT1s,其中等待执行花费800ms,执行查询只用了200ms,很明显,发现等待执行耗时存在异常,此时我们就会去排查为什么等待执行耗费时间多,从而有针对性地对其优化。上面的优化过程可以总结为三个过程:

    • 合理正确测量时间花在哪
    • 分析时间为什么花在那
    • 针对耗时异常的确定方案优化

    2 性能剖析

        通过上面简要概述,了解到为了优化任务响应时间,就需要不断对系统做性能剖析。性能剖析主要测量和分析时间花费在哪,性能剖析需要完成的两个任务分别是测量任务所花费的时间和对测量结果统计排序分析

        测量任务的时间花费原理也很简单,在任务执行前启动计时器,在任务结束后停止计时器,然后使用结束时间减去开始时间,得到的就是任务响应时间。对于测量,需要做到准确测量和全量测量,如果不能得到准确的测量数据,后面基于这些数据做的分析都是徒劳无用的。测量最好全面,核心节点都需要测量到,这样更有利于分析。

        获取到测量数据后,一般需要对测量数据按照平均响应时间排序或者采用其他统计分析方法,从而获取到值得优化的任务,但是有一点需要铭记:执行时间占比小的任务优化收益不大,优化主要还是要着眼于执行时间占比大的任务。同时针对异常情况也要重点关注,分析的数据要全面,不能仅仅按照均值,要结合极值、中位数、方差等综合来看。

      上面讨论的都是以任务为基本单元的性能剖析,有点局限性,毕竟自用户发起请求到服务器响应,中间有多个处理过程,比如网络、外部依赖、中间数据处理、数据库查询、缓存查询等。所以针对从用户请求入口到服务器响应的整个过程分析性能会比较科学全面。

    2.1 剖析查询

    分析查询性能,主要分为两块:整体查询性能和单条查询性能。整体查询性能分析主要通过收集DB慢查询日志,DB慢查询日志主要统计了查询响应时间在设定阈值以上的的查询请求信息。DB日志一般分为慢查询日志和通用查询日志,都记录了查询请求的相关信息。

    通过整体查询分析后,可以得到性能比较差的查询请求,然后需要向下钻取这些性能差的查询请求,做定向分析。在mysql中有三种方法分析单条查询性能:

    • SHOW PROFILE
    • SHOW STATUS
    • 慢查询日志条目

    explain 也可以分析sql性能,但是explain是预估的信息

  • 相关阅读:
    偏最小二乘法回归(Partial Least Squares Regression)
    今天就来聊聊产品运营
    VS2005终于不“变态”了!
    Android 里的对话框Dialog 实现机制基础
    C#多线程操作界面控件的解决方案
    转C++ ,C#数据类型对照
    关于Linq to sql 应用时出现的一个‘row not found or changed’ 异常
    Android之Context Memu
    HttpModule的认识
    Docker:官网文档 Get Started 笔记
  • 原文地址:https://www.cnblogs.com/glsy/p/13034773.html
Copyright © 2020-2023  润新知