关于最近遇到的坑 - if queryset
背景 在python语法中,if obj是一种很简洁优雅的语法糖,可以用来判断字符串是否为空,某个参数是否为None,列表是否为空。所以,在面对queryset对象时便毫不犹豫的用if queryset来做判断,导致了性能问题。 class PageNumberPaginator(PageNumberPagination): .....省略无关代码 def paginate_queryset(self,queryset,request,ModelClass,view=None): self.total = None if queryset else get_total(queryset,ModelClass) return PageNumberPagination.paginate_queryset(self,queryset=queryset,request=request) def get_paginated_response(self,data,total=None): query_count = self.page.paginator.count return Response(OrderedDict([ (‘result‘,‘ok‘),(‘paging‘,OrderedDict([ (‘draw‘,self.draw),(‘page‘,self.page_param),(‘page_size‘,self.page_size),(‘count‘,query_count),(‘total‘,total if total else self.total or query_count), ])),(‘data‘,data) ])) 现在就来具体拆分并分析为什么不能用if queryset来判断queryset是否为空。 ? 技术拆解-关于if判断 关于if判断的问题其实就是bool类型的判断。默认情况下 1.if会尝试bool(obj) 2.调用obj.__bool__() 3.调用obj.__x__() 具体解析,在判断布尔类型时,if会调用内置的bool(obj),此函数只能返回True或False。bool(obj)的背后会先尝试调用obj.__bool__()方法,存在则返回obj.__bool__()方法的结果,如果不存在,bool(obj)会尝试调用x.__len__()。若返回0,则bool返回0,否则True。 所以我们可以自己扩展并撰写一个自定义满足布尔类型判断的对象。 class LenFunc: def __len__(self): print(‘len step >>>>>>>‘) return 1 def __repr__(self): return ‘LenFunc for __len__ test‘ class BoolFunc: def __bool__(self): print(‘bool step >>>>>>>‘) return True def __repr__(self): return ‘BoolFunc for __bool__ test‘ class MixFunc: def __len__(self): print(‘len step >>>>>>>‘) return 1 def __bool__(self): print(‘bool step >>>>>>>‘) return True def __repr__(self): return ‘MixFunc for __len__&__bool__ test‘ func_list = [LenFunc(),BoolFunc(),MixFunc()] for obj in func_list: print(obj) if obj: print(obj,‘is True rn‘) 运行结果如下: 特殊方法的调用是隐式的,一般情况下,我们是不需要关注这些内容的,除非对于我们自定义的类型进行扩展,想尝试python的内置语法糖,才需要满足协议。 另外如果是python内置的类型,比如list,str,bytearray那么CPython会抄近路,__len__实际上会直接返回PyVarObject里的ob_size属性。PyVarObject是表示内存中长度可变的内置对象的C语言结构体。直接读取这个值比调用一个方法快多了。 ? 技术拆解-queryset queryset实际上是Django的内置的Queryset的实例。具体由来这边就不做阐述了,有兴趣的可以翻阅源码。下面贴上QuerySet的定义 ? 相信对django熟悉的都知道queryset对数据库的查询结果是懒加载的。其实,真正的加载查询数据库数据的步骤,在__len__和__iter__都可以发现。 在__len__中会有两步调用 class QuerySet(object): ..... def __len__(self): self._fetch_all() return len(self._result_cache) def _fetch_all(self): if self._result_cache is None: self._result_cache = list(self._iterable_class(self)) if self._prefetch_related_lookups and not self._prefetch_done: self._prefetch_related_objects() 第一步self._fetch_all()会查询可迭代对象内所有结果,即进行数据库查询操作,赋值数据库查询的结果列表给当前实例queryset的_result_cache属性,把查询结果加载内存中。 第二步返回查询数据结果列表的长度 ? ? 综上分析原因 当在分页查询内进行if queryset判断时,默认先寻找__bool__方法,当前对象没有,便会调用__len__方法。此时queryset作为一个懒加载对象,本身是在分页完聚焦在分页的那几条数据(10,20,50,100 whatever)进行数据库查询,却因为在if调用了__len__方法而提前被触发数据库查询。 当面临查询结果特别大的时候,如需要被分页的结果有4w条,数据便会被加载在内存中,导致内存占用过高,特别是在大并发的线上环境,尤其会影响性能,造成内存占用,内存紧张,影响服务整体性能,造成卡顿,甚至服务直接down掉 ? 建议使用queryset.exists()来替代 def exists(self): if self._result_cache is None: return self.query.has_results(using=self.db) return bool(self._result_cache)
django版本1.11.2 如果有兴趣,大家可以翻阅下源码,具体了解内容。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |