性能测试-2022年9月12日
# 一、引言
为使信使达到可用状态，得到科学合理的性能预期，展开本次性能测试。
# 二、测试目标及完成条件
本次测试从以下几个方面进行测试：
- 数据量
- 整个系统会话数≥1万个
- 系统聊天数据≥100万条
- 单用户会话数≥1000个
- 单会话聊天数据≥1万条
- 系统用户数≥5000人
- 群聊人数≥200人
- 并发
- 200人并发登录响应时间≤3秒
- 群组消息投递率 ≥ 99%
- 并发消息≥100人
以上为本次测试的最低标准, 该指标可以满足大部分中小企业的使用场景.
# 三、测试机器性能
没有专业服务器,开了个VMware虚拟机
主机:
虚拟机:
所有服务启动完成服务器状态:
# 四、测试步骤
# 1. 用户注册测试
- 样本数 5000
- 响应时间图
- 汇总报告和汇总结果
- 数据库数据
结论： 整体响应时间平稳，5000用户全部注册成功，响应平均值14毫秒。
# 2. 长连接测试
- 启动前状态
- 5000长连接全部启动完成
- 启动完成后汇总报告
- 长链接13分钟状态
- 连续运行20小时
结论： 此过程包含系统登录请求和定时心跳。登录耗时均长15毫秒，长时间链接稳定无异常。
# 3. 用户创建会话测试
- 演示，大概就是这么个效果
- 千个会话滚动情况， 使用了虚拟dom
（此处应该有视频， 但是传不上来） 「VeryCapture_20220911233812.mp4」https://www.aliyundrive.com/s/Qt13cVVdj3R 点击链接保存，或者复制本段内容，打开「阿里云盘」APP ，无需下载极速在线查看，视频原画倍速播放。
- 千个会话内存占用情况
结论： 千个会话没有压力，但是在5000用户切换会话会有明显卡顿
# 4. 发送消息吞吐测试
- 每秒2000条 毫无压力， 此处前端处置有问题，消息会给到前端，but， 处理不过来， 需要修正，但是实际来讲，几乎没有一秒千条的场景，靠着键盘操作，不得整出火花来。
# 5. 200用户群测试
目前测试的200用户的群组消息发送耗时是141毫秒。 还是需要优化。有明显卡顿的感觉。 但是日常应该是够用的， 后续会继续改进
# 五、总结
本次成果：
- 用户的会话数支持
原先随着会话数的增加，大概在200个会话左右，页面会卡死，主要是由于dom数量的增加，系统占用内存增加的原因。本次优化使用了虚拟dom。理论是支持无限个，但是实测发现，会话数在5000个左右时，切换会话会异常卡顿。
- 消息数据量支持
房间内的消息随着数量的增加亦会导致内存飙升，同样会导致卡顿或崩溃。虚拟dom无法解决图片后加载的问题，所以此处是手动控制dom数量，但同时引发的问题就是大量的数据操作，无法完美的与后端吞吐匹配。后端数据到位，but，前端消息无法到位。
- 后端初始化
原先的节奏是大量的数据都通过直接访问数据库获取，但是量变引起质变，在5000用户数的情况下，单数据处置和返回需要超过1分钟的时间，本次优化从登录开始进行缓存。尽量减少这个过程。最终实测5000用户数的情况下仅需2秒左右，1000用户数几乎无感。
- 消息发送
因为设计上记录了未读数量等信息。导致的问题就是每次需要查库获得未读数列表，这个动作体现在每一个消息发送上， 这就导致在200用户群的情况下，发送消息需要超过2秒钟，这个是不可接受的，最终同样使用缓存的方式在服务端记录。发送消息仅入库，不查询。最终优化为140毫秒左右，但跟我的预期还是相差甚远。同样作为遗留问题继续改进。
- 数据库结构的变化
为了适应这些改动，调整了部分数据库的变化，将一些库表字段删除或冗余起来。减少不必要的数据库操作。
最终结论：
- 适应群体： 1000人以下的中小企业或项目
- 建议并发： 200人