企业官网建设流程全解析

gta5办公室网站正在建设,百度移动端网站,长沙网络公司,网站设计制作上海公司年轻的时候#xff0c;经常听一些大会或者演讲。有些人说#xff0c;思路逻辑非常重要。我那时就想#xff0c;你肯定是瞎忽悠的#xff0c;因为我怎么就没听懂你说的思路呢#xff1f; 而现在轮到自己来写或者讲一些东西的时候#xff0c;才发现他们说得很对#xff0…年轻的时候经常听一些大会或者演讲。有些人说思路逻辑非常重要。我那时就想你肯定是瞎忽悠的因为我怎么就没听懂你说的思路呢而现在轮到自己来写或者讲一些东西的时候才发现他们说得很对而我之所以不理解也是有原因的。性能分析思路和具体的实现之间有一道鸿沟那就是操作的能力。之前我为什么听不懂那些人的思路其实是因为我没有操作的功底。而有了操作的功底之后还有一个大的鸿沟要越过去那就是从操作到对监控计数器的理解。这一步可以说让很多性能测试人员都望而却步了。但是这还不算完这一步迈过去之后还有一个跳跃就是相关性分析和证据链分析的过程。如此一来就会得到一张性能测试分析的能力阶梯视图如下工具操作包括压力工具、监控工具、剖析工具、调试工具。数值理解包括上面工具中所有输出的数据。趋势分析、相关性分析、证据链分析就是理解了工具产生的数值之后还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。最后才是调优有了第 3 步之后调优的方案策略就有很多种了具体选择取决于调优成本和产生的效果。那么怎么把这些内容都融会贯通呢下面我们就来说说性能测试分析的几个重要环节。应该说从我十几年的性能工作中上面讲的这些内容是我觉得最有价值的内容了。在今天的文章中我们将对它做一次系统的说明。我先把性能分析思路大纲列在这里瓶颈的精准判断线程递增的策略性能衰减的过程响应时间的拆分构建分析决策树场景的比对。一、瓶颈的精准判断TPS 曲线对性能瓶颈做出判断是性能分析的第一步有了问题才能分析调优。之前有很多人在描述性能测试的过程中说要找到性能测试中曲线上的“拐点”。我也有明确说过大部分系统其实是没有明确的拐点的。举例来说TPS 的视图如下显然这是一个阶梯式增加的场景非常好。但是拐点在哪呢有人说显然在 1200TPS 左右的时候。也有人说了显然是到 1500TPS 才是拐点呀。但是也有人说这都已经能到 2000TPS 了显然 2000TPS 是拐点。我们再来看一下这张图对应的响应时间视图是不是有人要说响应时间为 4.5ms 时是拐点了其实这些对拐点的判断都是不合理的。如果我们对 TPS 的增加控制得更为精准的话那么这个 TPS 的增加是有一个有清晰的弧度而不是有一个非常清晰的拐点。但是至少我们可以有一个非常明确的判断那就是瓶颈在第二个压力阶梯上已经出现了。因为响应时间增加了TPS 增加得却没有那么多到第三个阶梯时显然增加的 TPS 更少了响应时间也在不断地增加所以性能瓶颈在加剧越往后就越明显。那么我们的判断就是有瓶颈瓶颈和压力有关。压力呈阶梯并且增长幅度在衰减。如果你觉得上面的瓶颈还算清晰的话那么我们再来看一张图在这个 TPS 的曲线中你还能判断出拐点在哪吗显然是判断不出来拐点的但是我们根据图得出以下几个结论有瓶颈瓶颈和压力有关。压力也是阶梯的但是并没有明确的拐点。我们再来看一个 TPS 图看到这张图是不是明显感觉系统有瓶颈呢那么瓶颈是不是和压力大小有关呢这种比较有规律的问题显然不是压力大小的原因。为什么呢因为 TPS 周期性地出现降低并且最大的 TPS 也都恢复到了差不多的水位上。所以即使是压力降低也最多降低最大的 TPS 水位会让问题出现得更晚一点但是不会不出现。综合以上如果画一个示意图的话TPS 的衰减过程大概会如下所示随着用户数的增加响应时间也在缓慢增加。TPS 前期一直都有增加但是增加的幅度在变缓直到变平。在这样的趋势图中我们是看不到明确的拐点的。但是我们能做的清晰的判断就是有瓶颈所以对 TPS 曲线来说它可以明确告诉我们的就是有没有瓶颈其实准确说所有的系统都有性能瓶颈只看我们在哪个量级在做性能测试了。瓶颈和压力有没有关系TPS 随着压力的变化而变化那就是有关系。不管压力增不增加TPS 都会出现曲线趋势问题那就是无关。这时你可能会问为什么不看响应时间就武断地下此结论呢其实响应时间是用来判断业务有多快的而 TPS 才是用来判断容量有多大的。响应时间的曲线我们还是来看看响应时间下面看一张响应时间图它对应的线程图是多明显的问题随着线程的增多响应时间也在增加是吧。再来看它们对应的 TPS 图到第 40 个线程时TPS 基本上达到上限为 2500 左右。响应时间随着线程数的增加而增加了系统的瓶颈显而易见地出现了。但是如果只让你看 TPS 曲线你是不是也会有同样的判断那就是有瓶颈并且和压力有关所以说其实 TPS 就可以告诉我们系统有没有瓶颈了而响应时间是用来判断业务有多快的。后面我们还会提到响应时间会是性能分析调优的重要分析对象。二、线程递增的策略讲完响应时间之后我们再来看下线程递增。在见识了很多性能测试人员做的场景之后必须得承认有些场景的问题太多了。首先我们来看两个场景的执行对比。场景 1 的线程图场景 1 的 TPS 图场景 1 的响应时间图场景 2 的线程图场景 2 的 TPS 图场景 2 的响应时间图这两个场景的比对如下有了这些对比数据之后你是不是觉得哪里似乎是有问题的对的TPS 都是达到 400但两个场景中线程递增的策略不同产生的响应时间完全不同。虽然都没有报错但是第一种场景是完全不符合真实的业务场景的。这是为什么呢在场景的执行过程中首先响应时间应该是从低到高的而在场景 1 中不是这样。其次线程应该是递增的而场景 1 并没有这样做这里或许有人会想到秒杀的场景认为场景 1 符合秒杀的业务设定这个问题我们稍后提及。最后在两个场景中TPS 的上限都达到了 400TPS。但是你可以看到在场景 2 中只要 40 个线程即可达到但场景 1 中居然用到了 500 线程显然压力过大所以响应时间才那么长。其实在生产环境中像场景 1 这样的情形是不会出现的。如果它出现了那就是你作为性能测试的责任因为你没有给出生产环境中应该如何控制流量的参数配置说明。同时我们从上面的场景对比可以看到对一个系统来说如果仅在改变压力策略其他的条件比如环境、数据、软硬件配置等都不变的情况下系统的最大 TPS 上限是固定的。场景 2 使用了递增的策略在每个阶梯递增的过程中出现了抖动这就明显是系统设置的不合理导致的。设置不合理有两种可能性1. 资源的动态分配不合理像后端线程池、内存、缓存等等2. 数据没有预热。我们再回到之前说的秒杀场景。说到秒杀场景有人觉得用大线程并发是合理的其实这属于认识上的错误。因为即使线程数增加得再多对已经达到 TPS 上限的系统来说除了会增加响应时间之外并无其他作用。所以我们描述系统的容量是用系统当前能处理的业务量你用 TPS 也好RPS 也好HPS 也好它们都是用来描述服务端的处理能力的而不是压力工具中的线程数。这一点我在第 5 篇文章中已经做了详细的解析你可以回去再看看。那么对于场景中线程有些工具中叫虚拟用户递增的策略我们要做到以下几点场景中的线程递增一定是连续的并且在递增的过程中也是有梯度的。场景中的线程递增一定要和 TPS 的递增有比例关系而不是突然达到最上限。后面在场景的篇幅中我们会再说它们之间的比例关系。上面两点针对的是常规的性能场景。对于秒杀类的场景我们前期一定是做好了系统预热的工作的在预热之后线程突增产生的压力也是在可处理范围的。这时我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增就是不合理的场景。这里给出我做性能场景递增的经验值当然这里也不会是放在哪个系统中都适合的递增幅度你还是要根据实际的测试过程来做相应的判断。有了这些判断之后相信大家都能做出合理的场景来了。三、性能衰减的过程有了瓶颈的判断能力也有了线程递增的意识那么下面在场景执行中我们就要有判断性能衰减的能力了吧。来我们先看一个压力过程中产生的结果图。在递增的压力过程中随着用户数的增加。我们可以做几次计算。第一次计算在线程达到 24 时TPS 为 1810.6也就是每线程每秒发出 75.44 个请求。第二次计算在线程达到 72 时TPS 为 4375.1也就是每线程每秒发出 60.77 个请求。第三次计算在线程达到 137 时TPS 为 5034也就是每线程每秒发出 36.74 个请求。通过这三次计算我们是不是可以看到每线程每秒发出的请求数在变少但是整体 TPS 是在增加的。我们有很多做性能测试的人基本上只看 TPS 和响应时间的时候在上面这个示例中肯定会一直往上加用户。虽然响应时间在增加但是增加得也不多嘛。但实际上通过我们的计算可以知道性能是在不断地衰减的。我们来看一张统计图通过红线的大致比对可以知道当每线程每秒的请求数降到 55 左右的时候TPS 就达到上限了大概在 5000 左右再接着往上增加线程已经没有用了响应时间开始往上增加了。这就是性能衰减的过程题外话在上图中其实还有一个问题就是在红线前面性能在上升的过程中有几次抖动这个抖动到后面变大了也变频繁了如果这是必然出现的抖动那也是配置问题希望你注意到这一点。为什么要这么细致地描述性能衰减的过程呢其实我就是想告诉你只要每线程每秒的 TPS 开始变少就意味着性能瓶颈已经出现了。但是瓶颈出现之后并不是说服务器的处理能力这里我们用 TPS 来描述会下降应该说 TPS 仍然会上升在性能不断衰减的过程中TPS 就会达到上限。这也是前面我说的性能瓶颈其实在最大 TPS 之前早就已经出现了。那么我们是不是应该在性能衰减到最大 TPS 时就停止场景呢这个不一定的哦。因为停不停场景取决于我们的场景目标如果我们只是为了得到最大 TPS那确实可以停止场景了。但是如果我们要扩大化性能瓶颈也就是说为了让瓶颈更为明显就完全不需要停止场景只要不报错就接着往上压一直压到我们要说的下一个话题——响应时间变长需要拆分。四、响应时间的拆分在性能分析中响应时间的拆分通常是一个分析起点。因为在性能场景中不管是什么原因只要系统达到了瓶颈再接着增加压力肯定会导致响应时间的上升直到超时为止。在判断了瓶颈之后我们需要找到问题出现在什么地方。在压力工具上看到的响应时间都是经过了后端的每一个系统的。那么当响应时间变长我们就要知道它在哪个阶段时间变长了。我们看下这张图。这应该是最简单的一个压力测试逻辑了。一个应用一个 DB结果也拆分出了 8 个时间段这还是在我没有加上压力工具自己所消耗的时间的情况下。如果我们要分析压力工具中的响应时间拆分的逻辑就是上面这个示意图。但是在真实的场景中基本上不是这样的。如果是内网那基本上都是连在一个交换机上所以通常是这样的在这样的拓扑中我们仍然可以拆出来 t1 到 t8 的时间。只是实际动手的时候思路一定要清晰时间拆分是从哪里到哪里要画出来不能混乱。我们有很多手段可以进行时间的拆分当然要看我们的应用支持哪一种。如果我们是这样的架构拆分时间应该是比较清楚的。首先我们需要查看 Nginx 上的时间。日志里就可以通过配置 requesttimeupstream_response_time 得到日志如下信息14.131.17.129 - - [09/Dec/2019:08:08:09 0000] GET / HTTP/1.1 200 25317 0.028 0.028AI写代码bash1最后两列中前面是请求时间的 28ms后面是后端响应时间的 28ms。同时我们再到 Tomcat 上去看时间。172.18.0.1 - - [09/Dec/2019:08:08:09 0000] GET / HTTP/1.1 200 25317 28 27 http-nio-8080-exec-1AI写代码bash1请求时间消耗了 28ms响应时间消耗了 27ms。接着再来看一下前端的时间消耗从这里可以看到从发出请求到接收到第一个字节即 TTFB 是 55.01ms内容下载用了 11.75ms。从这就可以看得出 Nginx 基本上没消耗时间因为它和 Tomcat 上的请求响应时间非常接近。那么网络上的消耗时间怎么样呢我看到有很多人用 TTFB 来描述网络的时间。先来说明一下TTFB 中显然包括了后端一系列处理和网络传输的时间。如下图所示下面的紫色点是指要接收的内容。上面的红色线就是 TTFB。如果接收完了呢就是这个状态所以我觉得用 TTFB 描述网络的健康状态并不合理。如果用 Content Download 来描述会更为合理。比如我们上面的这个例子中那就是 11.75ms 下载了 25317 Bytes 的内容。Tomcat 上基本上是消耗了处理的所有时间当然这中间也包括了 MySQL 花费的时间。而前端看到的其他时间就消耗在了网络中。在这个例子中主要说明了响应时间怎么一步步拆。当然如果你是下面这种情况的话再一个个拆就比较辛苦了需要换另一种方式。你肯定想知道每个系统消耗了多长时间那么我们就需要链路监控工具来拆分时间了。比如像这样来拆分从 User 开始每个服务之间的调用时间都需要看看时间消耗的监控。这就是时间拆分的一种方式。其实不管我们用什么样的工具来监控最终我们想得到的无非是每个环节消耗了多长时间。用日志也好用链路监控工具也好甚至抓包都可以。当我们拆分到了某个环节之后就有了下一步的动作构建分析决策树。五、构建分析决策树关于分析决策树我在很多场合也都有提及。分析决策树对性能测试分析人员实在是太重要了是性能分析中不可或缺的一环。它是对架构的梳理是对系统的梳理是对问题的梳理是对查找证据链过程的梳理是对分析思路的梳理。它起的是纵观全局高屋建瓴的指导作用。性能做到了艺术的层级之后分析决策树就是提炼出来的可以触类旁通的方法论。而我要在这里跟你讲的就是这样的方法论。应该说所有的技术行业在面对自己的问题时都需要有分析决策树。再广而推之的话所有的问题都要有分析决策树来协助。通过上面的几个步骤我们就会知道时间消耗在了哪个节点上。那么之后呢又当如何总要找到根本的原因才可以吧我画了如下的分析决策图从压力工具中只需要知道 TPS、响应时间和错误率三条曲线就可以明确判断瓶颈是否存在。再通过分段分层策略结合监控平台、日志平台或者其他的实时分析平台知道架构中的哪个环节有问题然后再根据更细化的架构图一一拆解下去。我在这里以数据库分析和操作系统分析举一下例子。首先我们看一下数据库分析决策树。比如针对 RDBMS 中的 MySQL我们就可以画一个如下的决策树由于这里面的内容实在过多无法一次性展现在这里。我举几个具体的例子给你说明一下。MySQL 中的索引统计信息有配置值有状态值。我们要根据具体的结果来判断是否需要增加 key_buffer_size 值的大小。比如这种就无所谓了。Buffer used 3.00k of 8.00M %Used: 0.04AI写代码bash1从上面的数据可以看到key buffer size 就用到了 4%显然不用增加。再比如我们看到这样的数据__Tables_______________________ Open 2000 of 2000 %Cache: 100.00 Opened 15.99M 4.1/sAI写代码bash123这就明显有问题了。配置值为 2000 的 Open Table Cache已经被占满了。显然这里需要分析。但是看到状态值达到配置值并不意味着我们需要赶紧加大配置值而是要分析是否合理再做相应的处理。比如说上面这个Table 确实打开得多但是如果我们再对应看下这一条。Slow 2 s 6.21M 1.6/sAI写代码bash1你是不是觉得应该先去处理慢 SQL 的问题了关于数据库的我们就不举更多的例子了。在这里只是为了告诉你在分析决策树的创建过程中有非常多的相互依赖关系。然后我们再来看一下操作系统分析决策树我在这里需要强调一下操作系统的分析决策树不可以绕过。如果你想到操作系统架构图就头大那么这时候应该觉得有了希望。那就是我觉得操作系统上的问题判断是比较清晰的所以基于此决策树每个人都可以做到对操作系统中性能问题的证据链查找。但是对嘛总得有个但是。对操作系统的理解是个必然的前提。我看过很多人写的操作系统性能分析方面的书籍或资料发现大部分人把描述计数器的数值当成性能分析。怎么理解这句话呢比如说“CPU 使用率在 TPS 上升的过程中从 10% 增加到 95%超过了预期值。” “内存使用率达到 99%所以是瓶颈点。” “I/O 使用率达到 100%。” 等等。这样的描述在我的性能团队中一定会被骂回去重写。我要这些描述有什么用我要的是为什么达到了这样的值原因在哪怎么解决就像分析决策树中所描述的那样性能工程师要做的是一步步地细化分析给出最终的原因。有人说如果按这个路子似乎操作系统的分析并不复杂嘛。大概三五个命令就可以跳到代码层了。是的对于操作来说确实不多但是对于判断来说那就复杂了。举个例子来说明一下看到这样的图你是不是有种手足无措的感觉中断能占 40%sy CPU 也能占 40%。这系统还用干业务的事吗全干自己的事去了可见操作系统有问题你是不是要做这个判断了而实际情况是这个主机上只有一个网卡队列而请求量又比较大。所以要解决的是网卡队列的问题至于怎么解决那手段就多了。可以换个服务器可以多加几个队列可以多接几个节点…以上只是给出几个性能分析过程中常见的决策树示例。在后续的分析过程实例中我们将秉承着这种分析思路一步步地走到瓶颈的面前。六、场景的比对为什么要写这一部分呢因为我看到很多人对瓶颈的判断并不那么精确所以想写一下场景比对的建议。其实简单来说就一句话当你觉得系统中哪个环节不行的时候 又没能力分析它你可以直接做该环节的增加。举例来我们现在有一个如下的架构可以得到这样的结果从 TPS 曲线中我们可以明显看到系统是有瓶颈的但是并不知道在哪里。鉴于系统架构如此简单我们索性直接在某环节上加上一台服务器变成这样然后得到如下数据哟没好使怎么办再接着加其他节点我加了更多的 JMeter 机器。再来看下结果真巧TPS 增加了看到了吧这就是我说的场景比对。当我们不知道系统中哪个环节存在性能瓶颈时对架构并不复杂的系统来说可以使用这样的手段来做替换法以快速定位问题。总结在这一篇中我说到了瓶颈的精准判断、线程递增的策略、性能衰减的过程、响应时间的拆分、构建分析决策树以及场景的比对这几个环节是性能分析过程中非常重要的环节。从我的经验上来说这一篇文章可能是我工作十几年的精华所在了。而这里的每一个环节又有非常多的细分特别是构建分析决策树这一块它需要太多的架构知识、系统知识、数据库知识等等。鉴于本文只是想起到一个提纲挈领的作用所以无法展开描述希望在后续的篇幅中我们尽量细致拆解。思考题今天的内容虽然有点多但总的来说思路比较清晰理解起来也比较容易。如果你认真学习了今天的内容不妨思考两个问题为什么线程递增过程不能断构建分析决策树的关键是什么总结感谢每一个认真阅读我文章的人作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。视频文档获取方式这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。