性能优化
这是以前工作中整理的文档，隐去部分内容后发布在这里，供参考。
原则
原则1：先保证主要功能及其基础功能，用户不卡顿，然后再考虑其它功能
目标：
第一阶段：保证首页和XX功能：无大并发时用户使用不卡顿。
第二阶段：保证首页和XX功能：有大并发时用户正常使用不卡顿。
第三阶段：保证其它功能：无大并发时用户使用不卡顿。
实施：
第一阶段，第一步：
- （测试）建立可验证的性能测试标准，用来验证优化结果（生成一个Excel表，记录操作的响应时间）
- （后台自查）查找已记录的可自己发现的性能问题，列出来，并与测试工具的情况进行对应。
- （前端自查）异步加载（部分呈现）。
第一阶段，第二步：评估方案和开发时间，并在指定时间使用测试工具进行验证，完成每一阶段的工作。
第二阶段：并发保证：
并发能力方案：
一、确定目标
- 系统运行保证的业务模块（典型场景-拼车），及其用户量（并发用户数/日）
- 将业务模块，功能点细化到具体的页面和操作，接口，数据量
结果：
接口或网页列表，目标承载力
二、测定现状: 目前各功能点能承载的压力（在不同并发数量和数量时的，响应时间和吞吐量，服务器负载）
基准测试：目前系统的响应时间和吞吐率
负载测试：找出目前系统的处理能力极限
三、性能优化和扩容方案：找到瓶颈，保证可通过增加服务器增加处理能力 - 达到目标的方法
- 超出目标时情况的处理（）
四、实施方案
五、验证目标 - 确定保证系统运行的功能点。
- 确定保证系统
操作：
产品和市场：确定典型应用场景，给出结果要求有具体的界面操作步骤。
压力测试组：基准测试和负载，结果要求：各操作步骤的，在不同并发量下的响应时间和吞吐量。
开发：找出性能瓶颈，给出改进方案，并实施。
细节方式：
拼车：算法，定期清理，GEOHash
接口要合并。
连带数据太多，没有数据还用全部列出
优先处理一部分性能问题：
- 后台发现的，吃资源的。
- 用户体验慢的。
在不用并发级别时的响应时间
代码级别性能排查（哪里在调用性能消耗大的情况）。
表数据量哪个大。
第一阶段：代码性能优化（变更细节）：
- 移除帐户白金卡相关内容
- 拼车匹配线路返回线路信息去掉根据订单计算线路状态的查询
- 拼车线路的用户批量传入
- 拼车线路是否可编辑，只在查询自己线路时计算。
- 查询我的线路和订单的方法，支持只查询数量（GetOrderAndRouteStatus慢）
- 当前时间改用本地服务器时间而不是从数据库获取
- 专家顾问查询使用批量，并去掉不需要的标记(已关注和有交易的标记)。
- 获取商家详情：商家是否加入了各种联盟，改为统一处理。
第一阶段结果
实施：
- 找出最常用的接口，提高其处理速度，减少其资源占用
- 找出在循环中访问数据库的地方，改为批量处理（记录数据库查询的次数和时间）
- 找出慢查询（记录数据库查询的次数和时间）
- 找出方式检测并处理长时间运行的操作，并强制放弃.
- 使用异步代码，避免长I/O操作占用所有线程，以至新请求不能处理
关于取消长时间运行的操作（Asp.net web api)
- asp.net Response.IsClientConneccted
- 参考：ASP.NET Web API + Long running operation cancellation
基于Interceptor性能测量和调整
- Autofac Interceptor对性能影响评估：thoughput 200/sec -> 300/sec
- 数据库查询：MsgCount的操作thoughput仅为58/sec
- 使用Interceptor记录数据库查询的次数和时间（）