（ 转）性能测试--地铁模型分析

标签：学习   ref   导致   大小   tle   大量   post   指标   logs   

地铁模型分析

　　和绝大部分人一样，小白每天都要乘坐地铁上下班，那么就拿地铁来分析，再次深刻理解下性能。早上乘坐地铁上班，最典型的就是北京地铁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、增大连接数）。
• 场景九：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

　　分析到这里，小白可以熟练地把性能指标与场景结合运用起来了，初步学习成果还是不错的。

原文：http://book.51cto.com/art/201502/465238.htm

（ 转）性能测试--地铁模型分析

标签：学习   ref   导致   大小   tle   大量   post   指标   logs   

原文地址：http://www.cnblogs.com/abcd19880817/p/7210816.html