今天发现 fabu.io 的一个小bug,

当一个活动的参与人数上到一定量的时候, response慢的令人发指,

一开始觉得这是一个很奇怪的问题,

因为已经用了Paginator, 每次Select应该不会这么慢

看源码才发现一个严重失误.

源码是呈现这样的一种形式

foo_info_list = [foo.info for foo in Foo.objects.filter(attr=boo)]
paginator = Paginator(foo_info_list, page_size)

好吧 这样的话结果当然慢的令人发指。

因为Django的分页器接受的对象只要是Iterable就可以，

所以当时是这么用的， 没有考虑到数据变大时的性能问题。

 

后来将foo_queryset代替现有的foo_info_list传入Paginator， 问题得以解决。

 

 

 

 

PS：

今天给www-data配置shell的时候不小心在passwd中写错了shell的路径

直接无法以www-data身份操作

查了下发现有个很不错的命令叫做chsh 远门用于切换用户shell

 

PPS：为什么我这么晚还在写Blog， 是因为我本来要配置qa服务器， 结果连不上去