一次优化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这块需要好好设计设计，规划一下了，但毕竟还是偷懒了。这次这个项目暴露出的之前设计上的不合理真的很重要，它直接改变了我对下一个项目（素材发布共享平台）的结构的设计。

很难想象如果再晚点发现，当这一套糟糕的模型已经用在多个项目中后，会有多麻烦。

本系列到此结束，谢谢