一次优化web项目的经历记录（一）

一次优化web项目的经历记录

这段时间以来的总结与反思

前言：最近很长一段时间没有更新博客了，忙于一堆子项目的开发，严重拖慢了学习与思考的进程。开水倒满了需要提早放下杯子，晚了就会烫手，这段时间以来，写的东西越来越不严谨，各种低级错误频出，早该停下总结并巩固一下了，但出于一些原因一直没付诸于行，终于，烫到手了

---

第一章：50分钟打不开的一个网页

---

事故现场为互联网上的一个角落

我负责的一个社会实践微足迹项目的管理员端登陆页面（准确的说，我负责的部分是后端+用户h5、微信前端页面，管理员端页面是交由X负责，我提供数据），接到反馈说，校级管理员在登录页卡了50min（从21:00到21:50）。亲测结果虽然没那么夸张，但也用了将近3分钟（考虑到管理员网络状况、失去耐心刷新页面，以及”反正是网页卡住了我先喝杯咖啡”等动作，他花了50min才打开网页是可信的）。如此还了得，不想继续打喷嚏就赶紧修复

---

为什么访问这么慢呢？瓶颈在哪儿？

根据chrome开发者工具的Network日志来看，其实登录接口(login)在一瞬间就完成了（700ms），主要是卡在了拉取信息的接口(overview)。这个接口原本是要返回一个信息概览的，但X为了简tou单lan，要求在这里就拿到所有会用到的数据，导致单接口要处理的任务较多。但就算如此也不应该会卡这么久，显然是什么地方设计错了。

---

第一想到的当然是数据库

众所周知，数据库连接是很耗时的，一般来说大部分项目的瓶颈都发生在数据库上。但我当初创建数据库的时候我是做过精心设计的，借助sqlalchemy做orm（忘了说了，这次后端用的python来写），合理的使用foreignKey与relationship，其实已经是很优的做法了，虽然后来发现仍然有可优化的空间，但那绝不是造成如此巨大耗时的原因。

话虽是这么说，但当事实（141s的延时）放在眼前时，很难有这么大的自信不去怀疑自己，为此做了很多无用功，耽误了不少时间。不过在boss兼学长兼老师的L帮助下，虽然没解决问题但确实加深了对原生SQL语句的理解运用。

（就个人来说，数据库比较复杂时通常就直接用orm了，所以说更大的收获其实是让我更加认识到了sqlalchemy背后所做的工作到底为我省了多少事情）

---

这样的话就麻烦了

在折腾了半天后醒悟到不是数据库的瓶颈后，我意识到这次的问题可能会有些麻烦了，不是那种能一眼发现恍然大悟进而分分钟搞定的bug。如果不去实际的做点什么，简单的分析代码猜测原因只是在浪费时间。

这里不得不提的是，Docker确实是很方便的技术，但毕竟使得代码部署多了一层容器，一定程度上确实会给修复bug调整代码造成一些麻烦，你不得不重构你的镜像，重启你的容器（除非你用volume把代码挂载到宿主机上，但这不就失去了一键交付、快速部署的意义了吗，我通常只在开发环境中这么做）。

嘛，比起它的好处来说这也不算什么，我只是想说，如果你只是做个很小的玩具，它负责测试你的想法，实验你的灵感，而你经常会随意修改它并且不打算集群部署发布或者交付给其它人使用，那么你大概不需要Docker。

---

好吧，那么下面我就得调试我的代码，监控它的运行并找出耗时瓶颈

下面的内容才是重点，是我一定要记录下这次经历的原因所在，我们明天再继续