地铁模型分析
和绝大部分人一样,小白每天都要乘坐地铁上下班,那么就拿地铁来分析,再次深刻理解下性能。早上乘坐地铁上班,最典型的就是北京地铁1、5、10、13号线等,人多得简直没法形容!为了方便理解分析,先做如下假设。
某地铁站进站只有3个刷卡机。
人少的情况下,每位乘客很快就可以刷卡进站,假设进站需要1s。
乘客耐心有限,如果等待超过30min,就会暴躁、唠叨,甚至选择放弃。
按照上述的假设,最初会出现如下的场景。
场景一:只有1名乘客进站时,这名乘客可以在1s的时间内完成进站,且只利用了一台刷卡机,剩余2台等待着。
场景二:只有2名乘客进站时,2名乘客仍都可以在1s的时间内完成进站,且利用了2台刷卡机,剩余1台等待着。
场景三:只有3名乘客进站时,3名乘客还能在1s的时间内完成进站,且利用了3台刷卡机,资源得到充分利用。
想到这里,小白越来越觉得有意思了,原来技术与生活这么息息相关,真的可以快乐学习哦。随着上班高峰的到来,乘客也越来越多,新的场景也慢慢出现了。
场景四:A、B、C三名乘客进站,同时D、E、F乘客也要进站,因为A、B、C先到,所以D、E、F乘客需要排队,等A、B、C三名乘客进站完成后才行。那么,A、B、C乘客进站时间为1s,而D、E、F乘客必须等待1s,所以他们3位在进站的时间是2s。
通过上面这个场景可以发现,每秒能使3名乘客进站,第1s是A、B、C,第2s是D、E、F,但是对于乘客D、E、F来说,“响应时间”延长了。
场景五:假设这次进站一次来了9名乘客,根据上面的场景,不难推断出,这9名乘客中有3名的“响应时间”为1s,有3名的“响应时间”为2s(等待1s+进站1s),还有3名的“响应时间”为3s(等待2s+进站1s)。
场景六:假设这次进站一次来了10名乘客,根据上面的推算,必然存在1名乘客的“响应时间”为4s,如果随着大量的人流涌入进站,可想而知就会达到乘客的忍耐极限。
场景七:如果地铁正好在火车站,例如,著名的北京西站、北京站。每名乘客都拿着大小不同的包,有的乘客拿的包太大导致卡在刷卡机那(堵塞),这样每名乘客的进站时间就会又不一样。
小白突然想到,貌似很多地铁进站的刷卡机有加宽的和正常宽度的两种类型,那么拿大包的乘客可以通过加宽的刷卡机快速进站(增加带宽),这样就能避免场景七中的现象。
场景八:进站的乘客越来越多,3台刷卡机已经无法满足需求,于是为了减少人流的积压,需要再多开几个刷卡机,增加进站的人流与速度(提升TPS、增大连接数)。
场景九:终于到了上班高峰时间了,乘客数量上升太快,现有的进站措施已经无法满足,越来越多的人开始抱怨、拥挤,情况越来越糟。单单增加刷卡机已经不行了,此时的乘客就相当于“请求”,乘客不是在地铁进站排队,就是在站台排队等车,已经造成严重的“堵塞”,那么增加发车频率(加快应用、数据库的处理速度)、增加车厢数量(增加内存、增大吞吐量)、增加线路(增加服务的线程)、限流、分流等多种措施便应需而生。
分析到这里,小白可以熟练地把性能指标与场景结合运用起来了,初步学习成果还是不错的。
性能测试之地铁模型分析
发表于:2017-01-09
作者:网络转载
来源:
- 周排行
- 月排行
-   稳定性测试怎么做,这篇文章彻底讲透了!
-   Docker容器网络性能测试和调优策略
-   性能测试中TPS上不去的几种原因浅析
-   浅谈性能测试——软中断高问题排查
-   Beego、Nginx性能测试
-   用户愿意等待的时间-性能指标与建议
-   面试被问什么时候开始性能测试?如何答?
-   稳定性测试怎么做,这篇文章彻底讲透了!
-   浅谈性能测试——软中断高问题排查
-   干货|性能测试模型初探及应用方法分析
-   可靠性测试的基础知识——软件可靠性测试
-   Docker容器网络性能测试和调优策略
-   性能测试的需求分析
-   性能测试中的指标和术语