企业官网建设流程全解析

网站布局优化,书法网站开发的前景,新手建站广告联盟赚钱,公司法治企业建设#x1f345; 点击文末小卡片 #xff0c;免费获取软件测试全套资料#xff0c;资料在手#xff0c;涨薪更快性能测试概念我们经常看到的性能测试概念#xff0c;有人或称之为性能策略#xff0c;或称之为性能方法#xff0c;或称之为性能场景分类#xff0c;大概可以看… 点击文末小卡片 免费获取软件测试全套资料资料在手涨薪更快性能测试概念我们经常看到的性能测试概念有人或称之为性能策略或称之为性能方法或称之为性能场景分类大概可以看到性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释。针对这些概念我不知道你看到的时候会不会像我的感觉一样乱一个小小的性能测试就延伸出了这么多的概念并且概念之间的界限又非常模糊。就拿“压力测试”、“容量测试”和“极限测试”这三个概念来说吧。网上针对这三个名词的解释是这样的压力测试压力测试是评估系统处于或超过预期负载时系统的运行情况。压力测试的关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。在压力级别逐渐增加时系统性能应该按照预期缓慢下降但是不应该崩溃。压力测试还可以发现系统崩溃的临界点从而发现系统中的薄弱环节。容量测试确定系统可处理同时在线的最大用户数使系统承受超额的数据容量来发现它是否能够正确处理。极限测试在过量用户下的负载测试。“压力测试是在超过预期负载时系统的运行情况”“容量测试是使系统承受超额的数据容量来发现它是否能够正确处理”。来吧就算我语文不好我也认字的谁能告诉我这两者的区别是什么除了字不一样。如果再抽象一层说一下这些概念那就是这些概念都在描述性能测试的不同侧面。而这些侧面本身构不成策略构不成方法不能说是概念也不能说是理论。此文一出肯定会有人说既然你评价当前的概念混乱那你有什么好建议呢作为可能被集体轰炸的话题既然已经摆上了台面我还是要冒死给一个自己认为的合理定义性能测试针对系统的性能指标建立性能测试模型制定性能测试方案制定监控策略在场景条件之下执行性能场景分析判断性能瓶颈并调优最终得出性能结果来评估系统的性能指标是否满足既定值。这是我觉得唯一合理的概念定义下面我就把这个概念详细解释一下。性能测试需要有指标有人说我们在做项目的时候就没有指标老板只说一句系统压死为止。听起来很儿戏但这样的场景不在少数。在我看来把系统压死也算是一种指标。至于你用什么手段把系统“压死”那就是实现的问题了。你可以采用很多种手段告诉老板这系统还没压就死了 这也是你的贡献。而对“有指标”这个定义来说理论上合理的并且应该有的指标是时间指标、容量指标和资源利用率指标。而这里的指标又会有细分细分的概念又是一团乱。这个话题我们后面再描述。性能测试需要有模型模型是什么它是真实场景的抽象可以告诉性能测试人员业务模型是什么样子。比如说我们有100种业务但不是每个业务都需要有并发量可能只有50个业务有那就要把这些有并发的业务统计出来哪个业务并发多哪个业务并发少做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来的很多在线上不敢直接压测的企业都是这样做的。而随着互联网中零售业、云基础架构的全面发展有些企业直接在线上导流来做性能测试这种思路上的转变来源于架构的发展及行业的真实需要。但这并不能说明性能测试不需要模型了因为这个模型已经从生产流量中导过来了。这一点还是需要你认清的。但是对于其他的一些行业比如银行这类金融机构线上一个交易都不能错。像上面这样做的难度就太大了。所以这些行业中仍然需要在测试环境中用业务模型来模拟出生产的流量。同时也请你认清一点现在的全链路压测并没有像吹嘘得那么神乎其神很多企业也只是在线上的硬件资源上做压力而已并不是真正的逻辑链路修改。我在工作中经常会被问到性能流量直接从生产上导的话是不是就可以不用性能测试人员了性能测试人员就要被淘汰了这未免太短视了大家都盯着最新鲜的技术、方法、概念各层的领导也都有自己的知识偏好万一做了一个决定影响了最终的结果有可能会让很多人跟着受罪。我之前带过的一个团队中开发架构们一开始就规划了特别详细的微服务架构说这一套非常好。我说这个你们自己决定我只要在这里面拿到可用的结果就行。结果开发了不到两个月一个个微服务都被合并了还得天天加班做系统重构只留了几大中台组件。这是为什么呢因为不适用呀。同理性能测试也要选择适合自己系统业务逻辑的方式用最低的成本、最快的时间来做事情。性能测试要有方案方案规定的内容中有几个关键点分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了这些内容具体的信息还需要精准。你可能会说怎么没有测试计划我的建议是用项目管理工具单独画测试计划比如用Project或OmniPlan之类的工具。这是因为在方案中写测试计划基本上只能写一个里程碑再细化一点就是在里面再加几个大阶段的条目。但是用项目管理工具做计划就不同了它不仅可以细分条目还能跟踪各个工作的动态进度可以设置前后依赖关系填入资源和成本以便计算项目偏差。性能测试中要有监控这个部分的监控要有分层、分段的能力要有全局监控、定向监控的能力。关于这一点我将在第三模块详细说明。性能测试要有预定的条件这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说在场景执行之前这些条件应该是确定的。有人说我们压力中也会动态扩展。没问题但是动态扩展的条件或者判断条件也是有确定的策略的比如说我们判断CPU使用率达到80%或I/O响应时间达到10ms时就做动态扩展。这些也是预定的条件。关于这一点在我的工作经历中经常看到有性能测试工程师对软硬件资源、测试数据和执行策略分不清楚甚至都不明白为什么要几分钟加几个线程。在这种情况之下就不能指望这个场景是有效的了。性能测试中要有场景可以说“性能场景”这个词在性能测试中占据着举足轻重的地位只是我们很多人都不理解“场景”应该如何定义。场景来源于英文的scenario对性能场景中的“场景”比较正宗的描述是在既定的环境包括动态扩展等策略、既定的数据包括场景执行中的数据变化、既定的执行策略、既定的监控之下执行性能脚本同时观察系统各层级的性能状态参数变化并实时判断分析场景是否符合预期。这才是真正的场景全貌。性能场景也要有分类在我有限的工作经验中性能场景从来都没有超出过这几个分类。基准性能场景这里要做的是单交易的容量为混合容量做准备不要跟我说上几个线程跑三五遍脚本叫基准测试在我看来那只是场景执行之前的预执行用来确定有没有基本的脚本和场景设计问题不能称之为一个分类。容量性能场景这一环节必然是最核心的性能执行部分。根据业务复杂度的不同这部分的场景会设计出很多个在概念部分就不细展开了我会在后面的文章中详细说明。稳定性性能场景稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中稳定性测试基本没和生产一致过。在稳定性测试中显然最核心的元素是时间业务模型已经在容量场景中确定了而时间的设置应该来自于运维周期而不是来自于老板、产品和架构等这些人的心理安全感。异常性能场景要做异常性能场景前提就是要有压力。在压力流量之下模拟异常。这个异常的定义是很宽泛的在下一篇文章里我们再细说。很多性能测试工程师都把场景叫成了测试用例。如果只是叫法不同我觉得倒是可以接受关键是内容也出现了很大的偏差这个偏差就是把用例限定在了描述测试脚本和测试数据上并没有描述需要实时的判断和动态的分析。这就严重影响了下一个概念性能结果。性能测试中要有分析调优一直以来需不需要在性能测试项目中调优或者说是不是性能测试工程师做调优人们有不同的争论。从性能市场的整体状态来看在性能测试工程师中可以做瓶颈判断、性能分析、优化的人并不多所以很多其他职位上的人对性能测试的定位也就是性能验证并不包括调优的部分。于是有很多性能项目都定义在一两周之内。这类项目基本上也就是个性能验证并不能称之为完整的性能项目。而加入了调优部分之后性能项目就会变得复杂。对于大部分团队来说分析瓶颈都可能需要很长时间这里会涉及到相关性分析、趋势分析、证据链查找等等手段。所以就要不要进行调优我做了如下划分。对性能项目分为如下几类。新系统性能测试类这样的项目一般都会要求测试出系统的最大容量不然上线心里没底。旧系统新版本性能测试类这样的项目一般都是和旧版本对比只要性能不下降就可以根据历史数据推算容量对调优要求一般都不大。新系统性能测试优化类这类的系统不仅要测试出最大容量还要求调优到最好。对性能团队的职责定位有如下几种。性能验证针对给定的指标只做性能验证。第三方测试机构基本上都是这样做的。性能测试针对给定的系统做全面的性能测试可以得到系统最大容量但不涉及到调优。性能测试分析调优针对给定的系统做全面的性能测试同时将系统调优到最优状态。当只能做性能验证的团队遇到旧系统新版本性能测试类和新系统性能测试优化类项目那就会很吃力这样的团队只能做新系统性能测试类项目。当做性能测试的团队遇到需要新系统性能测试优化类项目照样很吃力。这样的团队能做前两种项目。只有第三个团队才能做第三种项目。性能测试肯定要有结果报告性能结果如何来定义呢有了前面监控的定义有了场景执行的过程产生的数据就要整理到结果报告中了。这个文档工作也是很重要的是体现性能团队是否专业的一个重要方面。并不是整理一个Word美化一下格式就可以了。测试报告是需要汇报或者归档的。如果是内部项目测试报告可能就是一个表格发个邮件就完整了另外归档也是必须的。而对一些有甲乙方的项目就需要汇报了。那么如何汇报呢我们要知道大部分老板或者上司关心的是测试的结果而不是用了多少人花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的TPS、响应时间以及资源对比图。有了上面的的解析相信你对性能测试的定义有了明确的感觉了。这个定义其实就是描述了性能测试中要做的事情。当然也许会有人跳出来说你这个说得太重了不够敏捷。现在不都用DevOps了吗还要按这个流程来走一遍吗显然有这种说法的人没有理解我要说的主旨。以上的内容是针对一个完整的项目或系统或公司的系统演进。对于一些半路就跟着版本和新需求一轮轮迭代做下去的人的处境会不同因为这样的人只看到了当前的部分而不是整个过程。并且这个过程也是不断在迭代演进的。不管是敏捷开发过程还是DevOps你可以一条条去仔细分析下项目中的各个环节我说的是整个项目从无到有都不会跳出以上定义如果有的话请随时联系我我好改定义。:)通过图示最后总结一下性能测试的概念​有了这个图示之后就比较清晰了。所以前面所说的压力测试、容量测试、负载测试等等在实际的项目实施过程中都不具备全局的指导价值。我个人认为你应该在性能领域中抛弃这些看似非常有道理实则毫无价值的概念。性能场景TPS和响应时间前面我们说了性能要有场景也说了性能场景要有基准性能场景、容量性能场景、稳定性性能场景、异常性能场景。下面我将对前面说到的概念进行一一对应。学习性能的人一定看吐过一张图现在让你再吐一次。如下​在这个图中定义了三条曲线、三个区域、两个点以及三个状态描述。三条曲线吞吐量的曲线紫色、利用率绿色、响应时间曲线深蓝色。三个区域轻负载区Light Load、重负载区Heavy Load、塌陷区Buckle Zone。两个点最优并发用户数The Optimum Number of Concurrent Users、最大并发用户数The Maximum Number of Concurrent Users。三个状态描述资源饱和Resource Saturated、吞吐下降Throughput Falling、用户受影响End Users Effected。我在很多地方都看到了对这张图的引用。应该说做为一个示意图它真的非常经典的确描述出了一个基本的状态。但是示意图也只能用来做示意图在具体的项目中我们仍然要有自己明确的判断。我们要知道这个图中有一些地方可能与实际存在误差。首先很多时候重负载区的资源饱和和TPS达到最大值之间都不是在同样的并发用户数之下的。比如说当 CPU 资源使用率达到 100% 之后随着压力的增加队列慢慢变长响应时间增加但是由于用户数增加的幅度大于响应时间增加的幅度之前TPS 仍然会增加也就是说资源使用率达到饱和之后还有一段时间TPS才会达到上限。大部分情况下响应时间的曲线都不会像图中画得这样陡峭并且也不一定是在塌陷区突然上升更可能的是在重负载区突然上升。另外吞吐量曲线不一定会出现下降的情况在有些控制较好的系统中会维持水平。曾经在一个项目中因为TPS维持水平并且用户数和响应时间一直都在增加由于响应时间太快一直没有超时。我跟我团队那个做压力的兄弟争论了三个小时我告诉他接着压下去已经没有意义就是在等超时而已。他倔强地说由于没有报错时间还在可控范围所以要一直加下去。关于这一点争论我在后续的文章中可能还会提及。最优并发数这个点通常只是一种感觉并没有绝对的数据用来证明。在生产运维的过程中其实我们大部分人都会更为谨慎不会定这个点为最优并发而是更靠前一些。最大并发数这个点就完全没有道理了性能都已经衰减了最大并发数肯定是在更前的位置呀。这里就涉及到了一个误区压力工具中的最大用户数或线程数和TPS之间的关系。在具体的项目实施中有经验的性能测试人员都会更关心服务端能处理的请求数即TPS而不是压力工具中的线程数。这张图没有考虑到锁或线程等配置不合理的场景而这类场景又比较常见。也就是我们说的TPS上不去资源用不上。所以这个图默认了一个前提只要线程能用得上资源就会蹭蹭往上涨。这张图呢本来只是一个示意用以说明一些关系。但是后来在性能行业中有很多没有完全理解此图的人将它做为很有道理的“典范”给一些人讲从而引起了越来越多的误解。此图最早的出处是2005年Quest Software的一个PSO Consultant写的一个白皮书 《Performance Testing Methodology》。在18页论述了这张图原文摘录一段如下You can see that as user load increases, response time increases slowly and resource utilization increases almost linearly. This is because the more work you are asking your application to do, the more resources it needs. Once the resource utilization is close to 100 percent, however, an interesting thing happens – response degrades with an exponential curve. This point in the capacity assessment is referred to as the saturation point. The saturation point is the point where all performance criteria are abandoned and utter panic ensues. Your goal in performing a capacity assessment is to ensure that you know where this point is and that you will never reach it. You will tune the system or add additional hardware well before this load occurs.按照这段描述这个人只是随着感觉在描述一种现象除此无它。比如说The saturation point is the point where all performance criteria are abandoned and utter panic ensues.在我的工作经验中其实在saturation point之前性能指标就已经可以显示出问题了并且已经非常panic了而我们之所以接着再加压力是为了让指标显示得更为明显以便做出正确的判断。而调优实际上是控制系统在饱和点之前这里有一个水位的问题控制容量到什么样的水位才是性能测试与分析的目标。我们简化出另一个图形以说明更直接一点的关系。如下所示​上图中蓝线表示TPS黄色表示响应时间。在TPS增加的过程中响应时间一开始会处在较低的状态也就是在A点之前。接着响应时间开始有些增加直到业务可以承受的时间点B这时TPS仍然有增长的空间。再接着增加压力达到C点时达到最大TPS。我们再接着增加压力响应时间接着增加但TPS会有下降请注意这里并不是必然的有些系统在队列上处理得很好会保持稳定的TPS然后多出来的请求都被友好拒绝。最后响应时间过长达到了超时的程度。在我的工作中这样的逻辑关系更符合真实的场景。我不希望在这个关系中描述资源的情况因为会让人感觉太乱了。为什么要把上面描述得如此精细这是有些人将第一张图中的Light load对应为性能测试Heavy Load对应为负载测试Buckle Zone对应为压力测试……还有很多的对应关系。事实上这是不合理的。下面我将用场景的定义来替换这些混乱的概念。为什么我要如此划分因为在具体场景的操作层面只有场景中的配置才是具体可操作的。而通常大家认为的性能测试、负载测试、压力测试在操作的层面只有压力工具中线程数的区别其他的都在资源分析的层面而分析在很多人的眼中都不算测试。拿配置测试和递增测试举例吧。在性能中我们有非常多的配置像JVM参数、OS参数、DB参数、网络参数、容器参数等等。如果我们把测试这些配置参数称为“配置测试”我觉得未免过于狭隘了。因为对于配置参数来说这只是做一个简单的变更而性能场景其实没有任何变化呀。配置更改前后会用同样的性能场景来判断效果最多再增加一些前端的压力实际的场景并没有任何变化所以我觉得它不配做为一个单独的分类。再比如递增测试在性能中基准性能场景也好容量性能场景也好哪个是不需要递增的呢我知道现在市场上经常有测试工程师直接就上了几百几千线程做压力请你不要告诉我这是个正常的场景鉴于我的精神有限承受不了这样的压力。除了秒杀场景同时上所有线程的场景我还没有见到过。在一般的性能场景中递增都是必不可少的过程。同时递增的过程也要是连续的而不是100线程、200线程、300线程这样断开执行场景这样是不合理的。关于这一点我们将在很多地方着重强调。所以我觉得递增也不配做一个单独的分类。其他的概念就不一一批驳了。其实在性能测试中在实际的项目实施中我们并不需要这么多概念这些杂七杂八的概念也并没有对性能测试领域的发展起到什么推进作用。要说云计算、AI、大数据这些概念它们本身在引导着一个方向。而性能测试中被定为“测试”本身就处在软件生存周期的弱势环节当前的市场发展也并不好。还被这些概念冲乱了本来应该有的逻辑的思路实在是得不偿失。理解TPS、QPS、RT、吞吐量这些性能指标通常我们都从两个层面定义性能场景的需求指标业务指标和技术指标。这两个层面需要有映射关系技术指标不能脱离业务指标。一旦脱离你会发现你能回答“一个系统在多少响应时间之下能支持多少TPS”这样的问题但是回答不了“业务状态是什么”的问题。举例来说如果一个系统要支持1000万人在线可能你能测试出来的结果是系统能支持1万TPS可是如果问你1000万人在线会不会有问题这估计就很难回答了。我在这里画一张示意图以便你理解业务指标和性能指标之间的关系。​这个示意显然不够详细但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的而技术指标和业务指标之间也要有详细的换算过程。这样一来技术指标就不会是一块飞地。同时在回答了技术指标是否满足的同时也能回答是否可以满足业务指标。有了这样的关联关系下面我们看一下性能测试行业常用的性能指标表示法。我将现在网上能看到的性能指标做了罗列其中不包括资源的指标。因为资源类的比较具体并且理解误差并不大但业务类的差别就比较大了。对这些性能指标都有哪些误解我记得我还年轻的时候还没有QPS、RPS、CPS这样的概念只有TPS。那个时候天总是那么蓝时间总是那么慢“你锁了人家就懂了”。QPS一开始是用来描述MySQL中SQL每秒执行数Query Per Second所有的SQL都被称为Query。后来由于一些文章的转来转去QPS被慢慢地移到了压力工具中用来描述吞吐量于是这里就有些误解QPS和TPS到底是什么关系呢RPS指的是每秒请求数。这个概念字面意思倒是容易理解但是有个容易误解的地方就是它指的到底是哪个层面的Request如果说HTTP Request那么和Hits Per Second又有什么关系呢HPS这也是个在字面意思上容易理解的概念。只是Hit是什么有人将它和HTTP Request等价有人将它和用户点击次数等价。CPS用的人倒是比较少在性能行业中引起的误解范围并不大。同时还有喜欢用CPMCalls Per Minute每分钟调用数的。这两个指标通常用来描述Service层的单位时间内的被其他服务调用的次数这也是为什么在性能行业中误解不大的原因因为性能测试的人看Service层东西的次数并不多。为了区分这些概念我们先说一下TPSTransactions Per Second。我们都知道TPS是性能领域中一个关键的性能指标概念它用来描述每秒事务数。我们也知道TPS在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用TPS一定要有一个前提就是所有相关的人都要知道你的T是如何定义的。经常有人问TPS应该如何定义这个实在是没有具体的“法律规定”那就意味着你想怎么定就怎么定。通常情况下我们会根据场景的目的来定义TPS的粒度。如果是接口层性能测试T可以直接定义为接口级如果业务级性能测试T可以直接定义为每个业务步骤和完整的业务流。我们用一个示意图来说明一下。​如果我们要单独测试接口1、2、3那T就是接口级的如果我们要从用户的角度来下一个订单那1、2、3应该在一个T中这就是业务级的了。当然这时我们还要分析系统是如何设计的。通常情况下积分我们都会异步而库存不能异步哇。所以这个业务你可以看成只有1、2两个接口但是在做这样的业务级压力时3接口也是必须要监控分析的。所以性能中TPS中T的定义取决于场景的目标和T的作用。一般我们都会这样来定事务。接口级脚本——事务start接口1接口1脚本——事务end接口1——事务start接口2接口2脚本——事务end接口2——事务start接口3接口3脚本——事务end接口3业务级接口层脚本就是用接口拼接出一个完整的业务流——事务start业务A接口1脚本 - 接口2同步调用接口1脚本 - 接口3异步调用——事务end业务A用户级脚本——事务start业务A点击0 - 接口1脚本 - 接口2同步调用点击0 - 接口1脚本 - 接口3异步调用——事务end业务A你要创建什么级别的事务完全取决于测试的目的是什么。一般情况下我们会按从上到下的顺序一一地来测试这样路径清晰地执行是容易定位问题的。重新理解那些性能指标概念搞清楚了TPS的T是什么下面就要说什么是TPS了。字面意思非常容易理解就是每秒事务数。在性能测试过程中TPS之所以重要是因为它可以反应出一个系统的处理能力。我在很多场景中都说过事务就是统计了一段脚本的执行时间并没有什么特别的含义。而现在又多加了其他的几个概念。首先是QPS如果它描述的是数据库中的Query Per Second从上面的示意图中来看其实描述的是服务后面接的数据库中SQL的每秒执行条数。如果描述的是前端的每秒查询数那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用QPS来描述系统整体的性能以免产生误解。RPSRequest per second每秒请求数。看似简单的理解但是对于请求数来说要看是在哪个层面看到的请求因为请求这个词实在是太泛了。我们把上面的图做一点点变化来描述一下请求数。​如果一个用户点击了一次发出来3个HTTP Request调用了2次订单服务调用了2次库存服务调用了1次积分服务那么这个Request该如何计算如果你是算GDP的专家我觉得可能会是32218次。而在具体的项目中我们会单独描述每个服务以便做性能统计。如果要描述整体最多算是有3个RPS。如果从HTTP协议的角度去理解那么HTTP Request算是一个比较准确的描述了但它本身的定义并没有包含业务。如果赋予它业务的含义那么用它来描述性能也是可以的。HPSHits Per Second每秒点击数。Hit一般在性能测试中都用来描述HTTP Request。但是也有一些人用它描述真正的客户在界面上的点击次数。关于这一点就只有在具体的项目中才能规定得具体一些。当它描述HTTP Request时如果RPS也在描述HTTP Request那这两个概念就完全一样了。CPS/CPMCalls Per Second/ Calls Per Minutes每秒/每分钟调用次数。这个描述在接口级是经常用到的比如说上面的订单服务。显然一次客户界面上的点击调用两次。这个比较容易理解。但是在操作系统级我们也经常会听到系统调用用call来形容比如说用strace时你就会看见Calls这样的列名。这些概念本身并没有问题但是当上面的概念都用来描述一个系统的性能能力的时候就混乱了。对于这种情况我觉得有几种处理方式用一个概念统一起来。我觉得直接用TPS就行了其他的都在各层面加上限制条件来描述。比如说接口调用1000 Calls/s这样不会引起混淆。在团队中定义清楚术语的使用层级。如果没有定义使用层级那只能在说某个概念的时候加上相应的背景条件。所以当你和同事在沟通性能指标用哪些概念时应该描述得更具体一些。在一个团队中应该先有这些术语统一的定义再来说性能指标是否满足。响应时间RT在性能中还有一个重要的概念就是响应时间Response Time。这个比较容易理解。我们接着用这张示意图说明​RT T2-T1。计算方式非常直接简单。但是我们要知道这个时间包括了后面一连串的链路。响应时间的概念简单至极但是响应时间的定位就复杂了。性能测试工具都会记录响应时间但是都不会给出后端链路到底哪里慢。经常有人问问题就直接说我的响应时间很慢。问题在哪呢在这种情况下只能回答不知道。因为我们要先画架构图看请求链路再一层层找下去。比如说这样​在所有服务的进出口上都做记录然后计算结果就行了。在做网关、总线这样的系统时基本上都会考虑这个功能。而现在随着技术的发展链路监控工具和一些Metrics的使用让这个需求变得简单了不少。比如说这样的展示​它很直观地显示了在一个请求链路上每个节点消耗的时间和请求的持续时间。我顺便在这里说一下调优在当前性能项目中的状态。对于响应时间来说时间的拆分定位是性能瓶颈定位分析中非常重要的一节。但是请注意这个环节并不是性能测试工程师的最后环节。在工作中我经常看到有很多性能测试工程师连时间拆分都不做只报一个压力工具中看到的响应时间就给一个通过不通过的结论丝毫没有定位。另外有一些性能测试工程师倒是用各种手段分析了时间的消耗点但是也觉得自己的工作就此结束了而不做根本原因的分析或协调其他团队来分析。当然在不同的企业里做分析的角色和要求各不相同所以也要根据实际的企业现状来说。在我的观点中性能只测不调那就是性能验证的工作称不上是完整的性能项目。第三方性能测试的机构可以这样做但是在一个企业内部这样做的话性能团队的价值肯定就大打折扣了。但是现在有很多人都不把性能调优做为性能团队的工作主要原因有几点性能测试团队的人能力有限做不到性能调优代价高耗时长不值得做。在我带的性能项目中基本上调优的工作都是我的团队主导的。性能团队当然不可能完全没有技术弱点所以在很多时候都是协调其他团队的人一起来分析瓶颈点。那为什么是我的团队来主导这个分析的过程呢因为每个技术人员对性能瓶颈的定义并不相同如果不细化到具体的计数器的值是多少才有问题有误解的可能性就很大。曾经我在某零售业大厂做性能咨询的时候一房间的技术人员开发、运维、DBA都有结果性能瓶颈出现了所有人都说自己的部分是没问题的。于是我一个个问他们是如何判断的判断的是哪个计数器值又是多少。结果发现很多人对瓶颈的判断都和我想像的不一样。举例来说DB的CPU使用率达到90%以上DBA会觉得没有问题因为都是业务的SQL并不是DB本身有问题。开发觉得SQL执行时间慢是因为DB有问题而不是自己写的有问题因为业务逻辑并没有错有问题的点应该是DB上索引不合理、配置不合理。你看同样的问题每个人的看法都有区别。当然也不能排除有些人就是想推诿责任。这时怎么办呢如果你可以把执行计划拿出来告诉大家这里应该创建索引而那里应该修改业务条件这时就具体了。压力工具中的线程数和用户数与TPS总是有很多人在并发线程数和TPS之间游荡搞不清两者的关系与区别。这两个概念混淆的点就是好像线程是真实的用户一样那并发的线程是多少就描述出了多少真实的用户。但是做性能的都会知道并发线程数在没有模拟真实用户操作的情况下和真实的用户操作差别非常远。在LoadRunner还比较红火的时候Mercury提出一个BTO的概念就是业务科技优化。在LoadRunner中也提出”思考时间“的概念其实在其他的性能工具中是没有“思考时间”这个词的。这个词的提出就是为了性能工具模拟真实用户。但是随着性能测试的地位不断下降以及一些概念和名词不断地被以讹传讹导致现在很多人都没有明白压力工具中的线程数和用户以及TPS之间是怎样的关系。同样我们先画一个示意图来说明一下。​这里先说明一个前提上面的一个框中有四个箭头每个都代表着相同的事务。在说这个图之前我们要先说明“并发”这个概念是靠什么数据来承载的。在上面的内容中我们说了好多的指标但并发是需要具体的指标来承载的。你可以说我的并发是1000TPS或者1000RPS或者1000HPS这都随便你去定义。但是在一个具体的项目中当你说到并发1000这样没有单位的词时一定要让大家都能理解这是什么。在上面这张示意图中其实压力工具是4个并发线程由于每个线程都可以在一秒内完成4个事务所以总的TPS是16。这非常容易理解吧。而在大部分非技术人的脑子里这样的场景就是并发数是4而不是16。要想解释清楚这个非常困难我的做法就是直接告诉别人并发是16就好了不用关心4个线程这件事。这在我所有项目中几乎都是一样的一直也没有什么误解。那么用户数怎么来定义呢涉及到用户就会比较麻烦一点。因为用户有了业务含义所以有些人认为一个系统如果有1万个用户在线那就应该测试1万的并发线程这种逻辑实在是不技术。通常我们会对在线的用户做并发度的分析在很多业务中并发度都会低于5%甚至低于1%。拿5%来计算就是10000用户x5%500(用户级TPS)注意哦这里是TPS而不是并发线程数。如果这时响应时间是100ms那显然并发线程数是500TPS/(1000ms/100ms)50(并发线程)。通过这样简单的计算逻辑我们就可以看出来用户数、线程数和TPS之间的关系了。​但是响应时间肯定不会一直都是100ms的嘛。所以通常情况下上面的这个比例都不会固定而是随着并发线程数的增加会出现趋势上的关系。所以在性能分析中我一直在强调着一个词趋势业务模型的28原则是个什么鬼我看到有些文章中写性能测试要按28原则来计算并发用户数。大概的意思就是如果一天有1000万的用户在使用系统如果开10个小时的话在计算并发用户数的时候就用2小时来计算即1000万用户在2小时内完成业务。我要说的是这个逻辑在一个特定的业务系统中是没有任何价值的。因为每个系统的并发度都由业务来确定而不是靠这样的所谓的定律来支配着业务。如果我们做了大量的样本数据分析最后确实得出了28的比例我觉得那也是可以的。但是如果什么数据都没有分析直接使用28比例来做评估和计算那就跟耍流氓没有区别。业务模型应该如何得到呢这里有两种方式是比较合理的根据生产环境的统计信息做业务比例的统计然后设定到压力工具中。有很多不能在线上直接做压力测试的系统都通过这种方式获取业务模型。直接在生产环境中做流量复制的方式或压力工具直接对生产环境发起压力的方式做压力测试。这种方式被很多人称为全链路压测。其实在生产中做压力测试的方式最重要的工作不是技术而是组织协调能力。相信参与过的人都能体会这句话的重量。响应时间的258原则合理吗对于响应时间有很多人还在说着258或2510响应时间是业内的通用标准。然后我问他们这个标准的出处在哪里谁写的背景是什么几乎没有人知道。真是不能想像一个谁都不知道出处的原则居然会有那么大的传播范围就像谣言一样出来之后再也找不到源头。其实这是在80年代的时候英国一家IT媒体对音乐缓冲服务做的一次调查。在那个年代得到的结果是2秒客户满意度不错5秒满意度就下降了但还有利润8秒时就没有利润了。于是他们就把这个统计数据公布了出来这样就出现了258 principle翻译成中文之后它就像一个万年不变的定理深深影响着很多人。距离这个统计结果的出现已经过去快40年了IT发展的都能上天了这个时间现在已经完全不适用了。所以以后出去别再提258/2510响应时间原则这样的话了太不专业。那么响应时间如何设计比较合理呢这里有两种思路推荐给你。同行业的对比数据。找到使用系统的样本用户越多越好对他们做统计将结果拿出来就是最有效的响应时间的制定标准。性能指标的计算方式我们在网上经常可以看到有人引用这几个公式。公式1并发用户数计算的通用公式其中C是平均的并发用户数n是login session的数量L是login session的平均长度T指考察的时间段长度。公式2并发用户数峰值C’指并发用户数的峰值C就是公式1中得到的平均的并发用户数。该公式是假设用户的login session产生符合泊松分布而估算得到的。仔细搜索之后发现会发现这两个公式的出处是2004年一个叫Eric Man Wong的人写的一篇名叫《Method for Estimating the Number of Concurrent Users》的文章。中英文我都反复看到很多篇。同时也会网上看到有些文章中把这个文章描述成“业界公认”的计算方法。在原文中有几个地方的问题。C并不是并发用户而是在线用户。这两个公式做了很多的假设条件比如说符合泊松分布什么的。为什么说这个假设有问题我们都知道泊松分布是一个钟型分布它分析的是一个系统在全周期中的整体状态。如果要让它在实际的项目中得到实用还需要有大量的统计数据做样本代入计算公式才能验证它的可信度。峰值的计算我就不说了我觉得如果你是做性能的应该一看就知道这个比例不符合大部分真实系统的逻辑。有些人把这两个公式和Little定律做比较。我要说Little定律是最基础的排队论定律并且这个定律只说明了系统中物体的平均数量等于物体到达系统的平均速率和物体在系统中停留的平均时间的乘积。我觉得这句话就跟秦腔中的”出门来只觉得脊背朝后“是一样一样的。有人说应该如何来做系统容量的预估呢。我们现在很多系统的预估都是在一定的假设条件之下的之所以是预估说明系统还不在或者还没达到那样的量。在这种情况下我们可以根据现有的数据做统计分析、做排队论模型进而推导以后的系统容量。但是我们所有做性能的人都应该知道系统的容量是演进来的而不是光凭预估就可以得出准确数值的。总结在性能测试的概念中性能指标、性能模型、性能场景、性能监控、性能实施、性能报告这些既是概念中的关键词也可以说是性能测试的方法和流程。而这些概念我们在实际的工作中都是非常重要的。因为它们要抹平沟通的误解。让不同层级不同角色的人可以在同样的知识背景下沟通也可以让做事情的人有清晰的逻辑思路同时对同行间的交流也有正向的促进作用。性能测试策略、性能测试场景、性能测试指标这些关键的概念在性能测试中深深地影响着很多人。我们简化它的逻辑只需要记住几个关键字就可以其他的都不必使用。性能测试概念中性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。性能场景中基准场景、容量场景、稳定性场景、异常场景。性能指标中TPS、RT。 记住T的定义是根据不同的目标来的在具体的性能项目中性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据性能中的数据我一直都不把它称之为模型因为在数据层面测试并没有做过什么抽象的动作只是使用、软硬件环境、分析模型等。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。