====== 交易监控中间件_压测 ======
===== 提测邮件 =====
刚刚，倩文，你好：

LIFEAPP提测，内容：新增交易监控

[监控对象]：监控生活应用[对外提供的服务]+[内部调用的服务]+[调用外部的服务]+[SQL](DBA有扫描慢查询，暂时不做SQL)

[落监控数据]：入参，出参，调外部系统名称，是否发生异常，开始时间，结束时间，耗时(毫秒)，机器ip，备注字段1,2,3(设计了一套表达式)

具体需求见：生活应用交易监控需求(V1.0).docx

具体设计见：生活应用交易监控设计.docx

@刚刚

发布步骤：
  - 设置lifeapp机器ip(10.199.105.184)
    - 获取主机 hostname：运行命令 hostname
    - 在/etc/hosts文件中配置：10.199.105.184 hostname
  - 执行update.sql
  - 发布uat最新代码
  - 信用卡相关交易走一遍，请观察la_trans_monitor[交易监控表]数据
@倩文

请帮忙做交易压测，新增交易监控，不应该影响系统性能(目前代码中比较少用到反射，并使用java异步+mq消费落监控数据)

注意：CMS查询/统计界面功能部分，预计明天/后天提测(子明开发中)
===== 业务测试 =====
<code>测试同学杨江帮忙走一遍正常业务流程，数据都落到la_trans_monitor交易监控表中。</code>
===== 压测结果 =====
<code>让压测同学唐倩文帮忙压测！</code>
Dear all,

测试结论：

1.repay dubbo接口TPS 124.4/秒，平均响应时间290ms，错误率28.16%，CPU在高并发的时候，用户CPU升至98%、系统CPU1.58%，当用户数降下来，用户CPU也能快速降下来。内存在正常范围内。

大致确定问题所在，错误率主要有3中场景，

一：业务繁忙，稍后再试，原因是由于高并发时cts现金宝份额被锁定，还没释放下一笔请求就过来了（该错误率占大多数，27.6%）。

二：处理中，原因是be处理较慢，返回给cts处理中，cts再返回给lifeapp处理中（该错误率占0.5%）。

三：通讯异常，稍后再试，原因是，lifeapp调beidou超时（该错误率占0.003%）。

优化建议：

因和信用卡相关的如绑卡、还款等均会落库，在数据量较大的情况下，可考虑增加历史表。

注：基于master又压了一次，和uat相比性能几乎无差别。
===== 分析压测报告 =====
Hi，各位：

对[倩文]的测试报告，整理了一下：

(1)TPS+平均响应时间+CPU 这三个指标，在正常范围内(具体值在下方)，但是错误率偏高：28.16%

(2)错误交易(28.16%)出现场景：
  - 业务繁忙，稍后再试，原因：并发使cts现金宝份额被锁定，返回报错，占27.6%
  - 处理中，原因：并发请求be(后续有模拟器系统)，返回处理中，占0.5%
  - 通讯异常，稍后再试，原因：并发请求beidou超时，占0.003%
(3)基于master又压了一次，和uat压的结果相比，性能几乎无差别

(4)优化建议：

因和信用卡相关的如绑卡、还款等均会落库，在数据量较大的情况下，可考虑增加历史表。

针对优化建议，我说明下：
  - 生活应用交易监控表，会落服务方法(提供对外/对内/访问外部)的监控数据，虽然量相对多一点，但是[使用java异步+mq消费]，对系统响应TPS没有影响，对用户体验没有影响
  - 交易监控数据多少，不会影响lifeapp交易，因为落交易监控表是异步mq处理，对系统响应TPS没有影响，对用户体验没有影响
  - 交易监控数据多少，会影响CMS交易监控查询功能，但是查询是从库，对主库没有影响
  - 针对倩文的建议，后续会慢慢设计优化方案，分库分表或者数据迁移

待刚刚CMS交易监控功能测试通过后，［交易监控］需求lifeapp和CMS一同上线！

另，感谢[倩文]下午帮忙压测lifeapp，666！