性能优化

未分类

原则

原则1：先保证拼车功能及其基础功能，少量用户不卡顿，然后再考虑其它功能
原则2：先保证拼车功能及其基础功能，大量用户并发使用时可用，然后再考虑其它功能

目标：

第一阶段：保证首页和拼车功能：无大并发时用户使用不卡顿。
第二阶段：保证首页和拼车功能：有大并发时用户正常使用不卡顿。
第三阶段：保证其它功能：无大并发时用户使用不卡顿。

实施：

第一阶段，第一步：

1. （司元帅）建立可验证的性能测试标准，用来验证优化结果（生成一个Excel表，记录操作的响应时间）
2. （后台自查）查找已记录的可自己发现的性能问题，列出来，并与测试工具的情况进行对应。
3. （前端自查）异步加载（部分呈现）。
   第一阶段，第二步：评估方案和开发时间，并在指定时间使用测试工具进行验证，完成每一阶段的工作。

第二阶段：并发保证：

并发能力方案：

一、确定目标
1. 系统运行保证的业务模块（典型场景-拼车），及其用户量（并发用户数/日）
2. 将业务模块，功能点细化到具体的页面和操作，接口，数据量
结果：
接口或网页列表，目标承载力
二、测定现状: 目前各功能点能承载的压力（在不同并发数量和数量时的，响应时间和吞吐量，服务器负载）
基准测试：目前系统的响应时间和吞吐率
负载测试：找出目前系统的处理能力极限
三、性能优化和扩容方案：找到瓶颈，保证可通过增加服务器增加处理能力
1. 达到目标的方法
2. 超出目标时情况的处理（）
四、实施方案
五、验证目标
1. 确定保证系统运行的功能点。
2. 确定保证系统

操作：

产品和市场：确定典型应用场景，给出结果要求有具体的界面操作步骤。
压力测试组：基准测试和负载，结果要求：各操作步骤的，在不同并发量下的响应时间和吞吐量。
开发：找出性能瓶颈，给出改进方案，并实施。

细节方式：

拼车：算法，定期清理，GEOHash
接口要合并。
连带数据太多，没有数据还用全部列出
优先处理一部分性能问题：
1. 后台发现的，吃资源的。
2. 用户体验慢的。

在不用并发级别时的响应时间
代码级别性能排查（哪里在调用性能消耗大的情况）。
表数据量哪个大。

第一阶段：代码性能优化（变更细节）：

1. 移除帐户白金卡相关内容
2. 拼车匹配线路返回线路信息去掉根据订单计算线路状态的查询
3. 拼车线路的用户批量传入
4. 拼车线路是否可编辑，只在查询自己线路时计算。
5. 查询我的线路和订单的方法，支持只查询数量（GetOrderAndRouteStatus慢）
6. 当前时间改用本地服务器时间而不是从数据库获取
7. 专家顾问查询使用批量，并去掉不需要的标记(已关注和有交易的标记)。
8. 获取商家详情：商家是否加入了各种联盟，改为统一处理。

第一阶段结果

慢接口优化结果对比(响应时间减少比例) 12月9~12日 VS. 12月16~20日

慢接口优化结果对比(响应时间数值) 12月9~12日 VS. 12月16~20日

原始数据

实施：

1. 找出最常用的接口，提高其处理速度，减少其资源占用
2. 找出在循环中访问数据库的地方，改为批量处理（记录数据库查询的次数和时间）
3. 找出慢查询（记录数据库查询的次数和时间）
4. 找出方式检测并处理长时间运行的操作，并强制放弃.
5. 使用异步代码，避免长I/O操作占用所有线程，以至新请求不能处理

关于取消长时间运行的操作（Asp.net web api)

1. asp.net Response.IsClientConneccted
2. 参考：ASP.NET Web API + Long running operation cancellation

Interceptor对性能影响评估：thoughput 200/sec -> 300/sec

数据库查询：MsgCount的操作thoughput仅为58/sec

使用Interceptor记录数据库查询的次数和时间（）