OMS 目前性能问题分析整理

问题思考

1、订单审单慢/取消代运营慢、报错

情况分析：
单个线程依次循环执行，单个订单很快，但是批量操作时累计起来就很慢了，而且在客户端长期等待后仍未得到结果，引发超时

第一次调整：启用线程池来处理，获取从数据库中获取需要校验的数据（如：北京地区EMS限重、仓库是否授权可开普通发票），调用JAVA组接口获取电子面单。
因为数据库与网络操作属于IO操作，不需要在线程内等待导致CPU资源的浪费，我采用协程的方式，即当线程将IO操作发出后，该线程继续处理下一个任务，当IO操作返回结果时，再触发空闲线程去处理之后的任务，以保证线程复用，处理大量任务时不需要开对等数量的线程去执行。

request.Products.Add(new WaybillGenerateRequest.ProductInfo { ProductName = "口袋A/V1", Num = 1 });
response = await apiClient.ExecuteAsync(request);
if (response.IsError)
{
    errMsgs.Add($"订单 {order.erp_rowid} 获取电子面单号失败，" + response.Message);
    return;
}

调整后出现的问题：
JAVA接口承受的请求数过大，触发熔断器直接返回错误

第二次调整
调整HTTP请求并发数，过大会造成JAVA接口的压力，过小会影响我这边服务的处理速度

后续可能存在的问题
JAVA接口：并发数仍然过大，导致接口直接返回错误
数据库：对数据库造成压力，因为同时处理订单的校验，可能会频繁并大量的从数据库获取数据

2、批量操作慢引发的客户端超时

情况分析：循环处理验证订单信息，之后依次调用以下存储过程，量大时会慢

(1)反审核

EXEC usp_auditing_reverse_operation 
@order_guid=@order_guid,@platform_rowid=@platform_rowid,
@reverse_operation_duty_name=@duty_name,@reverse_operation_duty_name_rowid=@duty_rowid

(2)换区域仓库

EXEC usp_warehouse_logistics_address_mod
@exec_type=1,@receiver_address_mod=0,@warehouse_mod=1,@logistics_mod=1,@order_guid=@order_guid,@platform_rowid=@platform_rowid, @receiver_address=@receiver_address,@receiver_city=@receiver_city,@receiver_district=@receiver_district,@receiver_mobile='',@receiver_phone='',@receiver_name='',@receiver_state=@receiver_state,@x_warehouse_name=@new_warehouse_name,@y_warehouse_name=@warehouse_name,@x_warehouse_rowid=@new_warehouse_rowid,@y_warehouse_rowid=@warehouse_rowid,@logistics_name='',@logistics_rowid=0,@logistics_bill_no='',@logistics_destination_code='',@package_center_name='',@electronic_bill_status=0,@duty_name=@duty_name,@km_duty_user_rowid=@duty_rowid,@logistics_order_rowid='',@express_logistics_status=@express_logistics_status

问题思考
因为目前不敢使用线程池的方式处理，防止对数据库造成过大的压力。
准备在客户端显示进度条，按照单个订单依次处理，虽然效率上未能提升，但不至于引发超时，并向操作人员显示任务执行进度，从而知道任务执行情况而非卡死

3、列表数据刷新、加载慢

情况分析：因为服务端的数据全部通过网络传输到客户端，受网络带宽限制，数据量大会影响网络传输的时间

问题调整
1、增加另一台服务器做负载均衡，较少单台服务器的压力
2、通过Gzip进行数据压缩，减少数据容量

问题思考
因为服务本身是用 protobuf 进行序列化后传输数据的，其实用 varint 编码，当文本信息过多时压缩效果明显，当数值类型过多时数据量不减反增加，所以再做一次 Gzip 压缩效果提升不大
审单界面数据传输量只减少了30%，未达到预期效果
在内网环境中，不使用压缩会更快

4、待确认优化的情况

(1)处理业务前数据校验

-- @rowid 为临时表
SELECT b.order_guid,b.platform_rowid,b.erp_rowid,b.y_order_guid,
b.advance_pack_status,b.pack_assemble_status,b.auditing_duty_name,b.agent_operation_status
FROM @rowids a JOIN order_erpform_master_b b ON a.Value=b.erp_rowid 

因为怕客户端界面上的数据为历史数据，所以均用类似以上的 SQL 从数据库里重新查了一遍，所以非常频繁，是否需要再做优化

(2)服务器配置

目前的服务对 CPU 和内存要求还不高，因为数据传输问题，使得带宽的大小完全影响了操作人员的感受，能否酌情调整目前使用的服务器配置，另外负载均衡所用的带宽未知

目前所使用的服务器：
1、63服务器：8核8G 15M
2、117服务器：8核32G 5M