• Python 踩坑记 -- 调优


    前言

    继续解决问题

    一个服务运行有点慢,当然 Python 本身不快,如果再编码不当那这个可能就是量级上的劣化。
    整个 Code 主线逻辑 1700+,各依赖封装 3000+,主线逻辑也是很久远的痕迹,长函数都很难看清楚一个 if else 的分支块到哪。
    主线逻辑理清楚后,剔除其中诸多已失去意义的逻辑和无效操作,但是整体功能运行时常并未缩短,深入看下具体卡点原因。
    调优肯定离不开 Profile 工具,参考下官方介绍:Python 性能分析器
    简单来说,就是可以,如下命令生成我们的 profile 分析文件

    python -m cProfile -o my_script.prof my_script.py
    

    再借助 flameprof 将 分析文件转为火焰图

    # 安装
    pip install flameprof
    
    # 将上文的 分析文件 my_script.prof 转图片
    python flameprof my_script.prof > my_script.svg
    

    性能开销
    上图可以看出,主要的性能开销是在 字符串的 splitlines 和 正则的 search 上,层层找下去,定位到 Code 逻辑:

    rules = [rule1, rule2, rule3, ...., rule50]
    source_text = [text1, text2, text3, ...., text400]
    
    def parse_data(text_str):
    	result = {}
    	for rule in rules:
    		do_one_rule(rule, text_str, result)
    	
    	search_objects = re.search(r'some_pattern', text_str)
    	if search_objects:
    		objects = search_objects.group.split('; ')
    		for obj in objects:
    			# do something
    			pass
    	
    
    def do_one_rule(rule, test_str, result):
    	for line in test_str.splitlines():
    		data = rule(line)
    		result.update(data)
    
    

    剔除多余分支,保留核心卡点逻辑,基本能识别出火焰图中卡点的根因了,这段 code 的目的是对文本中的内容做清理,得出想要的数据

    • 在每个 rule 的解析过程中,重复对原始的 test_str 做了 splitlines 的操作,直接就是性能途中一个主要卡点处
    • 正则中的匹配,首先有个不好习惯,没有去 compile pattern,并且 pattern 也是固定的,每次 search 的时都会重复执行 compile
    • 其次,这里的 search 实际功能就是匹配到其中某一行,而后再对该行处理,并且该行有一定特性,完全可以用字符串前缀匹配 和 关键字匹配来达到同样效果
    • 原始的文本 text_str 是由一些很大段的行可以先行剔除,来加速此处的匹配

    优化后效果:
    在这里插入图片描述
    可以看出,主要开销点都没有,直观测试效果是 原始的功能块从 耗时 15s + -> 3s -
    找出点了,仿佛也很简单,但是在长久迭代中,随着原始文本的增长,rule 的增多性能会有明显劣化。

    内存泄漏

    承接前文的的内存泄漏,修复了全局变量后,仍然会出现,内存的 profile 工具推荐 memray https://bloomberg.github.io/memray/getting_started.html,参考文档使用并不复杂。
    通过图形基本确定了开销点

    程序中会从 DB 读取全表数据,40w+ 行,整体会持续不断去 append 数组,这种不停数组扩容的情形,导致了有部分容量的内存够分配后不回收

    Flask 上下文不一致

    Flask 框架搭建服务,单个 app,使用了 werkzeug 的工功能来做 request 级别隔离的上下文管理,结果发现内容会串,无法做到 request 级别正确隔离,原始 code 如下

    from flask import Flask
    from werkzeug.local import Local, LocalManager
    
    local_store = Local()
    local_manager = LocalManager([local_store])
    
    
    app = Flask(__name__)
    app.wsgi_app = local_manager.make_middleware(app.wsgi_app)
    

    Flask 本身推荐了 g 用来做 request 级别的上下文存储,关于 Flask 的上下文 LocalLocalStackLocalProxy 是茫茫多的信息量,得空再细说吧。

  • 相关阅读:
    浅谈Oracle数据库调优(2)
    H5调用摄像头扫码详解
    接口自动化测试实战:JMeter+Ant+Jenkins+钉钉机器人群通知完美结合
    【数据聚类】第三章第三节4:类K-Means算法之二分K-均值算法(bisecting K-Means算法)
    准备好抛弃 HTML 了吗?Dart 3.1 和 Flutter 3.13 发布
    电机保护器究竟该怎么选择
    Ubuntu目录和linux内核文件用途
    解决 webpack 配置 sass-loader后报错,无法正常build
    shell——随机数(RANDOM)+ expect 自动应答
    Wireshark数据抓包分析之HTTP协议
  • 原文地址:https://blog.csdn.net/duxiangwushirenfei/article/details/139657284