一、某授权服务器生成授权码效率验证（http协议）
-
测试背景
在存量数据23万条的情况下，生成一条授权数据，需要10秒左右，用户反应数据生成效率太差，需要优化。初步判断是由于在授权数据生成时，有查询逻辑在数据生成之前导致。需进行压力验证。 -
测试场景设计
在满足用户当前存量数据的基础上，对可见的将来的数据增长进行可预估的数据模拟，并进行数据生成效率进行验证
①测试环境部署
CPU：8c（intel i3）
RAM：8g
②模拟23万条用户数据
③模拟50万条用户数据
④模拟100万条用户数据
⑤在数据量增加明显的情况下，数据查询效率验证 -
基准测试
①单条授权数据生成时间在13秒左右，消耗时间与生产环境类似，且从监控的后台服务器和数据服务器的资源消耗情况看，服务器无瓶颈，性能瓶颈判断为接口逻辑需要优化；
-
压力测试
①系统调优后，重新对序列号生成接口进行测试，验证优化结果
②分别基于23万、50万、100万条序列号的基础上进行单用户生成序列号效率验证
③23万条数据时，单接口，页面手动生成，多次验证，1次生成1个序列号的时间不到1秒（200毫秒）；查询（以单位、批次、序列号、合同）时间不到1秒；见截图
④50万条数据时，单接口，页面手动生成，多次验证，1次生成1个序列号的时间不到1秒（400毫秒）见截图
⑤50万条数据时，单接口，页面手动生成，多次验证，1次生成100个序列号的时间约7秒，见截图
⑥100万条数据时，单接口，页面手动生成，多次验证，1次生成1个序列号的时间不到1秒（700毫秒），见截图
⑦100万条数据时，单接口，页面手动生成，多次验证，1次生成100个序列号的时间约7秒，见截图
⑧100万条数据时，单接口，查询（以单位、批次、序列号、合同）时间约3秒，见截图
5. 测试结论
a. 授权服务经过调优后，性能有了极为明显的提升（13s—>1s）
b. 生成单条序列号时，在100万数据的基础上，不到1秒
c. 序列号查询时，在100万数据的基础上，以批次、合同号、序列号等方式进行查询，约3秒左右
d. 上述验证都是在1个并发（1个使用）的场景进行的测试，服务器资源使用较低，无性能瓶颈，未截图
二、freeipa登录相关接口验证（ldap协议）
- 测试背景
用户反馈在1000个左右域账户在早9：00—9：30登录高峰时，有部分无法登录；
在完成问题修复，并提供解决方案后，用户希望获取实际的压测数据进行方案验证。 - 测试场景设计
① 测试环境准备（使用行方现有测试环境）
环境：虚拟机
CPU：4c （2.0Ghz）
RAM：16g
② 数据准备：生成14000个测试账户
③ 模拟1000、2000、4000、8000用户登录场景
④ 通过多次持续压测，验证用户反馈场景（可复现）
⑤ 对代码进行调整后，设置并发用户1000、2000、4000、8000、10000等场景进行反复压测，以获取最优的并发用户数、响应时间、及吞吐量数值；在未见异常时，单次压测时间持续约30分钟 - 基准测试
① 准备总计约14000个账号，模拟dap并发登录，验证生产域控登录失败的问题；基础单接口场景，登录时间不到1秒（30毫秒） - 压力测试
①并发1000个用户时，接口响应时间约8秒；
②2000并发时，约16秒；
③4000并发时，约30秒；
④8000并发时，约70秒；
⑤10000并发时，在压测10分钟左右，出现异常，freeipa服务停止
⑥服务器监控（nmon）
- 测试结论
① 由压测结果分析，freeipa登录接口对系统cpu资源占用较高，在各个并发场景下，ipa docker 服务cpu资源都会几乎占满，但对内存使用影响不大；最优的并发用户数为1000，其吞吐量为130，响应时间为8秒；其他并发场景2000、4000、8000都可正常完成并发请求，吞吐量约120，响应时间随着并发用户的增加逐渐增大；更大并发用户数10000时，出现异常（ldap服务停止，需重启）；当前测试环境最大支持的并发用户数为8000
② 在对ldap配置优化调整后，测试环境最大可满足60秒8000人的并发登录需求；因ldap并发对cpu资源占用最高，而生产环境cpu配置比测试环境更高(4核–>8核)，且实际60秒登录8000人的可能性较低，预期生产环境可满足8000人以上并发登录需求
)
