写点什么

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

用户头像
J.Smile
关注
发布于: 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 日阅读数: 106
用户头像

J.Smile

关注

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

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

评论

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