一、某授权服务器生成授权码效率验证（http协议）

1. 测试背景
   在存量数据23万条的情况下，生成一条授权数据，需要10秒左右，用户反应数据生成效率太差，需要优化。初步判断是由于在授权数据生成时，有查询逻辑在数据生成之前导致。需进行压力验证。

2. 测试场景设计
   在满足用户当前存量数据的基础上，对可见的将来的数据增长进行可预估的数据模拟，并进行数据生成效率进行验证
   ①测试环境部署
   CPU：8c（intel i3）
   RAM：8g
   ②模拟23万条用户数据
   ③模拟50万条用户数据
   ④模拟100万条用户数据
   ⑤在数据量增加明显的情况下，数据查询效率验证

3. 基准测试
   ①单条授权数据生成时间在13秒左右，消耗时间与生产环境类似，且从监控的后台服务器和数据服务器的资源消耗情况看，服务器无瓶颈，性能瓶颈判断为接口逻辑需要优化；
   

4. 压力测试
   ①系统调优后，重新对序列号生成接口进行测试，验证优化结果
   ②分别基于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协议）

1. 测试背景
   用户反馈在1000个左右域账户在早9：00—9：30登录高峰时，有部分无法登录；
   在完成问题修复，并提供解决方案后，用户希望获取实际的压测数据进行方案验证。
2. 测试场景设计
   ①　测试环境准备（使用行方现有测试环境）
   环境：虚拟机
   CPU：4c （2.0Ghz）
   RAM：16g
   ②　数据准备：生成14000个测试账户
   ③　模拟1000、2000、4000、8000用户登录场景
   ④　通过多次持续压测，验证用户反馈场景（可复现）
   ⑤　对代码进行调整后，设置并发用户1000、2000、4000、8000、10000等场景进行反复压测，以获取最优的并发用户数、响应时间、及吞吐量数值；在未见异常时，单次压测时间持续约30分钟
3. 基准测试
   ①　准备总计约14000个账号，模拟dap并发登录，验证生产域控登录失败的问题；基础单接口场景，登录时间不到1秒（30毫秒）
4. 压力测试
   ①并发1000个用户时，接口响应时间约8秒；
   
   ②2000并发时，约16秒；
   
   ③4000并发时，约30秒；
   
   ④8000并发时，约70秒；
   
   ⑤10000并发时，在压测10分钟左右，出现异常，freeipa服务停止
   ⑥服务器监控（nmon）
   
5. 测试结论
   ①　由压测结果分析，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人以上并发登录需求