现象：某产品发布上线后经过一段时间的运行，管理员在管理门户上查询订单信息的操作耗时增加，影响操作体验。

分析：分析订单信息查询功能，发现订单信息展示时需要展示商品名称，而商品名称与订单信息不是同一个数据库，每次都需要根据商品ID调用服务去查询商品名称回来。在服务调用过程中当调用的服务次数多了，开销就增加了。

解决方案：根据订单信息第一屏中展示的内容，商品名称是需要通过服务调用获取的，因此采用空间换时间的方式将商品中心g_goods表的数据冗余一份到订单中心。当进行订单信息第一屏数据展示时，将订单中心的o_order_item与g_goods关联查询，减少中心间服务调用。

现象：现场有个客户使用的小程序，从客户点击登录按钮到客户信息展示的时间平均需要3S左右，无论在业务忙时还是在业务闲时耗时都差不多。

分析：对客户登录后的处理逻辑进行分析，发现展示的客户信息很多是依赖于调用外部服务返回，并且服务使用同步的方式进行调用。当一个外部服务响应不及时，则会造成客户登录后信息加载缓慢，甚至出现空白页面的情况。

解决方案：从客户体验出发将客户信息进行分块，系统内的客户信息在客户登录后优先返回到前端进行渲染展示。对于调用外部服务获取客户其他信息的处理改为异步调用的方式，当外部服务返回信息后再加载到前端页面进行展示。

优化后：客户登录后信息展示的耗时从3S提升到0.5S。

现象：客户在平台上订购权益商品后，客户无法立即使用购买权益商品的手机号码登录平台使用，引发客户投诉。

分析：分析客户无法立即使用权益的原因，发现是客户订购的权益商品没有立即送往对应的权益提供商进行开通导致。进一步分析发现没有及时送的原因是平台生成权益商品订购单后，需要送多个外部系统，而且是按照顺序一个个送。当其中一个系统出现问题后其它系统将被堵住，而送权益提供商的处理恰巧排在最末。

解决方案：调整权益商品订购单送外部系统的处理逻辑，将现有串行送外系的操作调整为并行同步给外系统，实现权益商品购买后能够立即送往权益提供商进行开通，各业务系统之间的操作相互隔离，互不影响。

现象：某产品查询客户可订购商品的功能，经过两年的需求迭代，校验规则越来越多，查询效率越来越慢。

分析：借助Arthas工具分析商品查询调用链上的每一步耗时，发现规则引擎执行耗时严重。进一步对规则引擎进行分析发现：

① 单个规格执行耗时很短，只需十几毫秒，但存在300多个规则，导致总体规则执行经常超过4S；

② 每次请求都重新生成了多个规则引擎对象，导致规则对象内存占用高达几G，从而频繁触发FullGC；

③ 业务逻辑对执行的规则缺少细分，所有规则都会执行。

解决方案：通过优化规则执行方法：

① 梳理出简单规则，简单规则不使用规则引擎engine.eval，改为直接比较法进行判断；

② 创建规则引擎池JsScriptEnginePool，减少规则引擎重复创建；

③ 业务规则增加状态，只检索有效的规则进行执行。

优化前：10个并发， tps在1.6左右，请求平均耗时7.5s（再增加并发量就大面积请求异常）。

优化后：100并发用户时，平均tps为102，请求平均耗时在1s内。

现象：某项目近两年的业务发展较快，每天新增订单大约6W。客户在进行订单查询时耗时越来越长，每次查询耗时达到3S以上。

分析：分析订单查询功能发现耗时长的主要原因是订单的数据量多，造成查询语句执行效率低。对业务场景进行分析发现1~2个月内的数据访问率在92%以上，3~6个月的数据访问率在7%左右，超过6个月的数据访问率在1%以下。

解决方案：根据分析结果对订单表oi_order_item进行瘦身，新增his_oi_order_item表用来存放超过半年的数据。同时对his_oi_order_item表的数据访问提供新服务。通过将订单表oi_order_item的数据化整为零，大幅提升订单查询效率，数据库压力下降明显。订单查询耗时从原来3S下降到0.5S。

现象：系统在已经上线运行超过半年，一直存在操作卡顿的现象，业务高峰期甚至5分钟就出现一次。

分析：通过分析系统出现卡顿时的应用状态，发现rights-intf应用在卡顿时所有的线程都出现响应不及时的情况，并且rights-intf应用也在频繁触发FullGC操作。在业务高峰期每5分钟触发一次FullGC。每次FullGC后老年代内存使用率从98%左右下降到50%左右。

解决方案：根据分析结果倒推，怀疑rights-intf应用的JVM Xms和Xmx设置太小，导致频繁触发FullGC操作。检查rights-intf应用的JVM Xms和Xmx 配置的为1G。将1G改为3G后观察rights-intf应用未发生FullGC操作，系统运行平稳，卡顿现象消失。