一、NJ地铁闸机测试点思维导图
二、实现流程图:
三、性能分析:
场景: | |
1、进站最大TPS响应时间及错误率 TPS:480--3200 响应时长1秒,错误率具体分析 | 600/4000为进出站共合,考虑时长段进出站的比例 上班高峰8点到8点半数据支持如下 |
2、出站最大TPS响应时间及错误率 TPS:480--3200 响应时长1秒, | |
3、运营人员报表汇总查询导出大数据量 |
数据支撑: |
日均客运量350 万人次(截至2020年12月) |
日最高客运量421.9 万人次(2020年12月31日) |
年客运量12.78 亿人次(2019年) |
420W(日最高人次)*2(进出)/17(运营时长)=50W(平场每小时进出站人次) 50W(平场每小时进出站人次)*4(系数)/60分=35000/M 50W*4/3600秒=583/S |
191座车站*20个闸机=4000/S |
数据准备 | |||
用户IC基础表 | 查/导出 | 1000W--5000W | 950WNJR乘系数 |
行程记录表 | 增/改 | 6亿 | 进出站一天300W*180天 |
用户财务表 | 增/导出 | 1000W--5000W | 同用户IC基础表 |
用户资金明细表 | 查/改导出 | 6亿 | 用户行程记录表 |
总结:
1、进出站调用有些表是共用的调用的,如上表格提到。
2、记录流水数据量过大常用表应该不支持导出,可以把要导的数据同步到新的表里进行导出,不影响使用频繁的表。
3、数据量可以考虑是否分表实现,考虑定期规档。
4、流水记录表相关,考虑一周的数据,用户对这些数据没有查询的需求,提高数据库性能。
5、响应时间时长1秒以上的数据量多了影响体验功能重点考虑。
6、查询相关的时长变慢考虑中间介实现。
喜欢我的分析思路路过的给我点个赞赞赞赞赞吧。
有什么不足的地方希望留意我改进,谢谢!