一次优化web项目的经历记录（三）
一次优化web项目的经历记录
这段时间以来的总结与反思
前言：最近很长一段时间没有更新博客了，忙于一堆子项目的开发，严重拖慢了学习与思考的进程。
开水倒满了需要提早放下杯子，晚了就会烫手，这段时间以来，写的东西越来越不严谨，各种低级错误频出，早该停下总结并巩固一下了。
但出于一些原因一直没付诸于行，终于，烫到手了
第三章：yield与generator
Footprint.get_pics() 里到底发生了什么呢？
抱歉，最近事情有点多，更新晚了，我们继续。get_pics 本身耗时100多s，然而其内部的几个函数耗时加起来居然远低于这个值，为什么呢？
我就不绕弯了，答案就是本章的标题，yield与generator。我是怎么确定的呢？因为目前还剩下的 get_pics 内部的仅有的几个方法里，最可疑的只有这个方法：iter_directory
iter_directory 是用来迭代阿里云oss上的某个目录（其实是前缀相同的所有对象），以得到其中的所有文件（对象）的。很显然，这个方法需要调用外部api！
而作为一个调用外部api的方法，其执行2679次的总耗时居然仅有0.03秒，我的天哪，怎么可能！
是我的监听器有什么漏洞吗？
按照我的代码逻辑，在某个被注册的方法进入前，将会获取当前时间戳一次，而在其退出后则立即得到时间差，累加进方法总耗时。
我们不妨假设这样一种情景：有一个方法f，其返回值为方法g。g不会在f内部得到执行，它仅仅被返回，并且在f外部被调用并执行，用python描述如下：
@monitor.register
def f():
def g():
pass
return g
...
if __name__ == '__main__':
g = f()
for _ in range(0, 1000):
g()
print monitor.report()那么很显然的，我的监听器实际上只监听了f方法的执行总耗时，而g的执行发生在f之外，成功“逃脱”了我的监视。
上面这个假设与yield有什么关系呢？
def f():
print '2'
yield 'f'
print '3'
if __name__ == '__main__':
print '1'
f()
print '4'来猜测一下，上面的几个数字的打印顺序是什么呢？1234？如果你这么认为，那或许你需要补一补迭代器的常识了：
正确的答案应该是14。是的，没有2，也没有3。当你执行 f() 时，函数 f 根本没有得到真正的调用！准确的说，函数 f 其实被调用了，但这个 f 却不是你说认识的 f！
是的，当函数或方法内部使用了yield关键字时，实际上它已经不再是它自己了。当你执行 f() ，真正发生的并不是 f 内部的东东顺序执行，而是构造了一个 迭代器。
只有你执行 f().next()，也就是在返回的迭代器上执行 next() 方法，代码才会从f 内部开始解释执行，知道遇到yield关键字并立即返回。
再次执行 next() 时，会从上次离开的地方继续。如果遇不到yield了，则已迭代完毕，抛出一个 StopIteration 。
现在真相大白了， iter_directory 这个方法就是造成瓶颈的真凶。很显然，由于 iter_directory 事实上是一个generator，注册它其实是监听了它的迭代器生成方法。得到的耗时其实仅仅是生成迭代器的耗时。
真正造成严重延时的真凶，就是访问阿里云oss查找对象的方法，而这个操作是虽然看似在 iter_directory 里，但其实是在它的迭代器构造方法之外的，所以检测不到。
接下来就没什么好说的了，找到了耗时的真凶就该对它做优化了。这很容易，我采取了缓存策略，从memcache上获取缓存的值，而不是每次都从阿里云里去查找，除非接到更新信号或memcache上的值为空。
这次的事故中我学到了什么呢？
首先是，自己留下的坑总会自己跳。当初学python时，对yield的理解仅限于迭代器模式的一种语法糖，而没有深刻的去了解其实现的机制，没有认识到其对原函数|方法的装饰改造效果。于是就有了这次的不愉快的踩坑经历。
其次，疲劳代码很容易出错。无论怎么想，我也不明白自己当初怎么会写出类似于“每次需要某值都遍历某树”这种可谓脑残低效至极的代码，唯一的解释就是累了，没有仔细思考布局。
甚至类似的地方，在这次优化过程中还发现了很多处，虽然最终验证影响都远不如这个地方那么大，但看着自己写出的这么糟糕的代码还是很让人不爽的。真希望抛开一切来一次大重构。
最后，定期的总结思考很重要。这次的问题最直接的原因其实还不是对yield理解不透彻，虽然这是个隐患，但这次的导火索是在阿里云对象存储这块的糟糕的设计。
以前只是简单的用过阿里云oss服务，而最近的几个项目却恰好都深度依赖于它。但由于几个项目时间都赶得比较紧，在阿里云oss这块就只能调通能用就过。
内心恐怕早也意识到oss这块需要好好设计设计，规划一下了，但毕竟还是偷懒了。这次这个项目暴露出的之前设计上的不合理真的很重要，它直接改变了我对下一个项目（素材发布共享平台）的结构的设计。
很难想象如果再晚点发现，当这一套糟糕的模型已经用在多个项目中后，会有多麻烦。
