培训列表页性能优化报告

---

响应时间和访问量

访问量 响应时间

---

• 访问量高峰期过万，平时日访问量过千
• 高峰期响应时间 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。 可见添加索引后性能大大提升。

---

我的优化到此结束，谢谢！