添加客服微信
400 035 7887
021-60725088-8054
泽众云测试 - 新闻动态 - Web-pr在线性能测试 - 正文
系统在做性能优化之前，有必要先了解下性能瓶颈在哪里，以下我们来讲讲系统会面临的性能瓶颈(各种性能堵塞场景)。
在高并发大量用户的场景下，系统一般会面临如下三个挑战：
1. 日益增长的用户数量
2. 日渐复杂的业务
3. 急剧膨胀的数据
这些挑战对于性能优化而言表现为：在保持和降低系统响应时间的前提下，不断提高系统吞吐量，提升流量高峰时期的服务可用性。
高并发面临的三个性能瓶颈：
反复缓存瓶颈
长请求瓶颈
多次请求累积瓶颈
1.反复缓存造成性能瓶颈
为了降低响应时间，系统往往在本地内存中缓存很多数据。缓存数据越多，命中率就越高，平均响应时间就越快。为了降低平均响应时间，有些开发者会不加限制地缓存各种数据，在正常流量情况下，系统响应时间和吞吐量都有很大改进。
但是当流量高峰来临时，系统内存使用开始增多，触发了JVM进行full GC，进而导致大量缓存被释放（因为主流Java内存缓存都采用SoftReference和WeakReference所导致的），而大量请求又使得缓存被迅速填满，这就是反复缓存。反复缓存导致了频繁的full GC，而频繁full GC往往会导致系统性能急剧恶化。
反复缓存所导致性能恶化的原因是无节制地使用缓存。缓存使用的指导原则是：工程师们在使用缓存时必须全局考虑，精细规划，确保数据完全缓存的情况下，系统仍然不会频繁full GC。
为了确保这一点，对于存在多种类型缓存以及系统流量变化很大的系统，设计者必须严格控制缓存大小，甚至废除缓存（这是典型为了提高流量高峰时可用性，而降低平均响应时间的一个例子）。
反复缓存反模式往往发生在流量高峰时候，通过线性增加机器和提高机器内存可以大大减少系统崩溃的概率。
2.长请求拥塞瓶颈
这是一种单次请求时延变长而导致系统性能恶化甚至崩溃的恶化模式。
对于多线程服务，大量请求时间变长会使线程堆积、内存使用增加，最终可能会通过如下三种方式之一恶化系统性能：
线程数目变多导致线程之间CPU资源使用冲突，反过来进一步延长了单次请求时间；
线程数量增多以及线程中缓存变大，内存消耗随之剧增，对于基于Java语言的服务而言，又会更频繁地full GC，反过来单次请求时间会变得更长；
内存使用增多，会使操作系统内存不足，必须使用Swap，可能导致服务彻底崩溃。
长请求拥塞反模式所导致的性能恶化现象非常普遍，所以识别该模式非常重要。
典型的场景如下：某复杂业务系统依赖于多个服务，其中某个服务的响应时间变长，随之系统整体响应时间变长，进而出现CPU、内存、Swap报警，在分布式环境下，从而引起连锁反应，最后造成雪崩的情况。
这种瓶颈模式的典型标识包括：被依赖服务可用性变低、响应时间变长、服务的某段计算逻辑时间变长等。
3.多次请求杠杆造成性能瓶颈
客户端一次用户点击行为往往会触发多次服务端请求，这是一次请求杠杆。
每个服务端请求进而触发多个更底层服务的请求，这是第二次请求杠杆。每一层请求可能导致一次请求杠杆，请求层级越多，杠杆效应就越大。
在多次请求杠杆反模式下运行的分布式系统，处于深层次的服务需要处理大量请求，容易会成为系统瓶颈。
与此同时，大量请求也会给网络带来巨大压力，特别是对于单次请求数据量很大的情况，网络可能会成为系统彻底崩溃的导火索。
多次请求杠杆所导致的性能恶化现象非常常见。
例如：对于推荐系统，一个用户列表请求会有多个算法参与，每个算法会召回多个列表单元（商家或者团购），每个列表单元有多种属性和特征，而这些属性和特征数据服务又分布在不同服务和机器上面，所以客户端的一次用户展现可能导致了成千上万的最底层服务调用。
对于存在多次请求杠杆反模式的分布式系统，性能恶化与流量之间往往遵循指数曲线关系。这意味着，在平常流量下正常运行服务系统，在流量高峰时通过线性增加机器解决不了可用性问题。所以，识别并避免系统进入多次请求杠杆反模式对于提高系统可用性而言非常关键。
推荐阅读：
性能测试报告包含哪些基本结构，完成一份性能测试报告需注意哪些方面？
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系SPASVO小编(021-60725088-8054)，我们将立即处理，马上删除。
alltesting@spasvo.com
.png)
