响应时间和访问量
访问量
响应时间
- 访问量高峰期过万，平时日访问量过千
- 高峰期响应时间 400~1000ms，平时400ms
- 2台服务器
- 500+行代码
代码结构问题
- 内部耦合性强，内聚性差
- 可读性差，注释少
- 代码质量差，潜伏bug多，出问题难以排查
优化目标
- 优化响应时间，800ms较慢
- 重构代码，加上必要注释，便于后期维护
性能优化
添加机器
mp_server_1
mp_server_2
分析：目前mobile-web两台机器，分析某一天（平常时候6月2号）机器，两台机器的CPU使用率，发现比较正常，没有过载的情况。五月底因为某一天访问量过高，CPU使用率一度升到40~60%。
优化方案：
通读代码，发现很多循环SQL的情况，即根据列表ID，循环查询数据库，可以将这些合并为一次IO，一次查询尽可能多的数据（在网络不是瓶颈的情况下）
不少方法内部逻辑类似，可以优化为一个方法
不少大表没有建相应的索引，全表扫描缓慢，可以针对性的建索引
循环查询优化
循环查询的代码：
pro_循环查询.JPG
使用 sqlalchemy in_语句，用mysql in来一次性查询，减少IO次数。
pro_循环优化.JPG
完全没有优化的情况：
get_status_方法未优化.JPG
未优化时候，getTrainingListWithStatus方法耗时1400+ms，优化后，响应时间减少到1300+ms，减少了100多ms。
get_status_优化后.JPG
合并相同逻辑优化
获取培训列表方法getTrainingList中，内部有个代码片段，循环调用了两个内部逻辑大致相同的方法，多了一次IO，优化一下，可以减少一倍的耗时。
get_train_list_未优化.JPG
get_train_list_重复逻辑的代码.JPG
可以合并为一个IO，然后作为参数传入这两个方法。
优化以后，get_train_list方法耗时从1000+ms降到500+ms，减少了一倍。
get_train_list优化以后.JPG
建索引优化：
培训列表涉及的数据表有：
- transporter_training; //表数据总量508，一个city_id 有15-50条数据; 目前有一个 id 索引；拟在上面建city_id索引
- transporter_training_course; //表数据总量19105，目前有id索引，teacher_id索引；拟在上面建（training_id,is_del）索引
- transporter_training_signup; //表数据50多万，目前只有一个id索引；拟建（transporter_id,is_valid,training_type）索引
- training_online;//表数据90多万，989802，目前只有一个id索引，为全表扫描；拟建 transporter_id 索引
添加索引后的优化情况
分析：添加索引后，整个training_list 耗时从1200+ms减少到890+ms。 可见添加索引后性能大大提升。
我的优化到此结束，谢谢！
