架构师训练营 -week7 命题作业

发布于: 2020 年 07 月 18 日
架构师训练营 -week7 命题作业

性能压测时,我们既想满足大并发用户的访问请求,又想让每次请求的响应时间尽可能的小,这样才能带给用户最佳的用户体验,不可能说想网购的时候,订单按钮点击了10分钟才反应过来,那估计网站早就倒闭了。

当比如双十一这种大促场景出现时,并发数一定是比平时多一个数量级的,那么随着并发数增加,系统会出现什么变化?

我们都可以感受到双十一的时候,有时候个页面可能点进去好几分钟才刷新出来,这就是说响应时间明显变慢了,那么此时吞吐量一定也不高,因为响应时间太久了,一个用户原本需要1s钟就打开了页面,现在却需要10s钟,速度慢了10倍,吞吐量肯定高不了。

然后我们用一个数学公式来衡量下为什么?

这个公式可以解释,为什么并发数增加到一定程度,吞吐量下降。一开始并发数增加缓慢,系统处理能力完全跟得上,比如CPU、内存、磁盘等影响我们应用程序运行的系统资源都很充裕,响应时间不会有什么明显变化,所以此时TPS类似于线性增长,一直到达临界点,比如上图的b点。但是b点之后继续增加并发用户数,随着TCP连接数增大,服务器系统资源逐渐减少,响应时间开始以较快增加,但此时并发数增加依然可以弥补响应时间增加带来的负性增长,也就是说吞吐量比如TPS依然在增大,但是此时速度已经缓慢。直到某个时刻,系统资源的减少已经让应用程序不堪重负,应用程序出现GC、卡顿、IO增加一系列影响处理的问题。此时已经到达系统的最大负载点,如图中c点,这时候响应时间开始指数级增加,TPS吞吐量开始急剧下降,直到系统崩溃比如d点。

所以,对于性能优化,我认为所有的优化和调整都是一个目标,那就是让操作系统或者服务器以更小的系统资源代价换取更多的处理能力,比如epoll多路复用、TCP滑动窗口/缓冲区大小、JVM调优、缓存使用、Mysql优化、算法改良等都是为了这个目标。

作为架构师,不但能够具有优化系统能力,还得未雨绸缪,比如当要考虑系统当前性能指标,规划未来的系统扩展能力,把控风险,资源最优化配置的权衡思维。可以做出选择,但是前提是选项要全面。

发布于: 2020 年 07 月 18 日 阅读数: 18
用户头像

Jeff.Smile

关注

努力支撑经历,经历支撑能力! 2018.12.03 加入

追不上BAT的人... 分享,聚焦

评论

发布
暂无评论
架构师训练营 -week7 命题作业