Python：记录一次Web接口优化

时间 2019-11-16

标签 python 记录一次 web 接口优化栏目 Python 繁體版

原文原文链接

背景

咱们负责的一个业务平台，有次在发现设置页面的加载特别特别地慢，简直就是使人发指html

让用户等待 36s 确定是不可能的，因而咱们就要开启优化之旅了。前端

投石问路

既然是网站的响应问题，能够经过 Chrome 这个强大的工具帮助咱们快速找到优化方向。python

经过 Chrome 的 Network 除了能够看到接口请求耗时以外，还能看到一个时间的分配状况，选择一个配置没有那么多的项目，简单请求看看：
web

虽然只是一个只有三条记录的项目，加载项目设置都须要 17s，经过 Timing, 能够看到总的请求共耗时 17.67s ，但有 17.57s 是在 Waiting(TTFB) 状态。算法

TTFB 是 Time to First Byte 的缩写，指的是浏览器开始收到服务器响应数据的时间（后台处理时间+重定向时间），是反映服务端响应速度的重要指标。

Profile 火焰图 + 代码调优

那么大概能够知道优化的大方向是在后端接口处理上面，后端代码是 Python + Flask 实现的，先不盲猜，直接上 Profile：sql

第一波优化：功能交互从新设计

说实话看到这段代码是绝望的：彻底看不出什么？只是看到不少 gevent 和 Threading，由于太多协程或者线程？数据库

这时候必定要结合代码来分析（为了简短篇幅，参数部分用 “...” 代替）：segmentfault

def get_max_cpus(project_code, gids):
    """
    """
    ...
    # 再定义一个获取 cpu 的函数
    def get_max_cpu(project_setting, gid, token, headers):
        group_with_machines = utils.get_groups(...)
        hostnames = get_info_from_machines_info(...)
        res = fetchers.MonitorAPIFetcher.get(...)
        vals = [
            round(100 - val, 4)
            for ts, val in res['series'][0]['data']
            if not utils.is_nan(val)
        ]
        max_val = max(vals) if vals else float('nan')
        max_cpus[gid] = max_val
       
    #  启动线程批量请求
    for gid in gids:
        t = Thread(target=get_max_cpu, args=(...))
        threads.append(t)
        t.start()
        
    # 回收线程
    for t in threads:
        t.join()

    return max_cpus

经过代码能够看到，为了更加快速获取 gids 全部的 cpu_max 数据，为每一个 gid 分配一个线程去请求，最终再返回最大值。后端

这里会出现两个问题：api

在一个 web api 作线程的 建立和销毁 是有很大成本的，由于接口会频繁被触发，线程的操做也会频繁发生，应该尽量使用线程池之类的，下降系统花销；
该请求是加载某个 gid (群组) 下面的机器过去 7 天的 CPU 最大值，能够简单拍脑壳想下，这个值不是实时值也不是一个均值，而是一个最大值，不少时候可能并无想象中那么大价值；

既然知道问题，那就有针对性的方案：

调整功能设计，再也不默认加载 CPU 最大值，换成用户点击加载（一来下降并发的可能，二来不会影响总体）；
由于 1 的调整，去掉多线程实现；

再看第一波优化后的火焰图：

此次看的火焰图虽然还有很大的优化空间，但起码看起来有点正常的样子了。

第二波优化：Mysql 操做优化处理

咱们再从页面标记处（接口逻辑处）放大火焰图观察：

看到好大一片操做都是由 utils.py:get_group_profile_settings 这个函数引发的数据库操做热点。

同理，也是须要经过代码分析：

def get_group_profile_settings(project_code, gids):
    
    # 获取 Mysql ORM 操做对象
    ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))
    session = get_postman_session()
    
    profile_settings = {}
    for gid in gids:
        compound_name = project_code + ':' + gid
        result = session.query(ProfileSetting).filter(
            ProfileSetting.name == compound_name
        ).first()
        
        if result:
            result = result.as_dict()
            tag_indexes = result.get('tag_indexes')
            profile_settings[gid] = {
                'tag_indexes': tag_indexes,
                'interval': result['interval'],
                'status': result['status'],
                'profile_machines': result['profile_machines'],
                'thread_settings': result['thread_settings']
            }
            ...(省略)
    return profile_settings

看到 Mysql ，第一个反应就是 索引问题，因此优先去看看数据库的索引状况，若是有索引的话应该不会是瓶颈：

很奇怪这里明明已经有了索引了，为何速度仍是这个鬼样子呢！

正当毫无头绪的时候，忽然想起在 第一波优化 的时候，发现 gid（群组）越多的影响越明显，而后看回上面的代码，看到那句：

for gid in gids: 
    ...

我仿佛明白了什么。

这里是每一个 gid 都去查询一次数据库，而项目常常有 20 ~ 50+ 个群组，那确定直接爆炸了。

其实 Mysql 是支持单字段多值的查询，并且每条记录并无太多的数据，我能够尝试下用 Mysql 的 OR 语法，除了避免屡次网络请求，还能避开那该死的 for

正当我想事不宜迟直接搞起的时候，余光瞥见在刚才的代码还有一个地方能够优化，那就是：

看到这里，熟悉的朋友大概会明白是怎么回事。

GetAttr 这个方法是Python 获取对象的 方法/属性 时候会用到，虽然不可不用，可是若是在使用太过频繁也会有必定的性能损耗。

结合代码一块儿来看：

def get_group_profile_settings(project_code, gids):
    
    # 获取 Mysql ORM 操做对象
    ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))
    session = get_postman_session()
    
    profile_settings = {}
    for gid in gids:
        compound_name = project_code + ':' + gid
        result = session.query(ProfileSetting).filter(
            ProfileSetting.name == compound_name
        ).first()
        ...

在这个遍历不少次的 for 里面，session.query(ProfileSetting) 被反复无效执行了，而后 filter 这个属性方法也被频繁读取和执行，因此这里也能够被优化。

总结下的问题就是：

1. 数据库的查询没有批量查询；
2. ORM 的对象太多重复的生成，致使性能损耗；
3. 属性读取后没有复用，致使在遍历次数较大的循环体内频繁 getAttr，成本被放大；

那么对症下药就是：

def get_group_profile_settings(project_code, gids):
    
    # 获取 Mysql ORM 操做对象
    ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))
    session = get_postman_session()
    
    
    # 批量查询 并将 filter 提到循环以外
    query_results = query_instance.filter(
        ProfileSetting.name.in_(project_code + ':' + gid for gid in gids)
    ).all()

    # 对所有的查询结果再单条处理
    profile_settings = {}
    for result in query_results:
        if not result:
            continue
        result = result.as_dict()
        gid = result['name'].split(':')[1]
        tag_indexes = result.get('tag_indexes')
        profile_settings[gid] = {
            'tag_indexes': tag_indexes,
            'interval': result['interval'],
            'status': result['status'],
            'profile_machines': result['profile_machines'],
            'thread_settings': result['thread_settings']
        }

            ...(省略)
    return profile_settings

优化后的火焰图：

对比下优化前的相同位置的火焰图：

明显的优化点：优化前的，最底部的 utils.py:get_group_profile_settings 和数据库相关的热点大大缩减。

优化效果

同一个项目的接口的响应时长从 37.6 s 优化成 1.47s，具体的截图：

优化总结

如同一句名言：

若是一个数据结构足够优秀，那么它是不须要多好的算法。

在优化功能的时候，最快的优化就是：去掉那个功能！

其次快就是调整那个功能触发的频率或者 复杂度！

从上到下，从用户使用场景去考虑这个功能优化方式，每每会带来更加简单高效的结果，嘿嘿！

固然不少时候咱们是没法那么幸运的，若是咱们实在没法去掉或者调整，那么就发挥作程序猿的价值咯：Profile

针对 Python 能够尝试： cProflile + gprof2dot

而针对 Go 可使用: pprof + go-torch

不少时候看到的代码问题都不必定是真正的性能瓶颈，须要结合工具来客观分析，这样才能有效直击痛点！

其实这个 1.47s，其实还不是最好的结果，还能够有更多优化的空间，好比：

前端渲染和呈现的方式，由于整个表格是有不少数据组装后再呈现的，响应慢的单元格能够默认先显示菊花，数据返回再更新；
火焰图看到还有挺多细节能够优化，能够替换请求数据的外部接口，好比再优化完全 GetAttr 相关的逻辑；
更极端就是直接 Python 转 GO；

可是这些优化已经不是那么迫切了，由于这个 1.47s 是比较大型项目的优化结果了，绝大部分的项目其实不到 1s 就能返回

再优化可能付出更大成本，而结果可能也只是从 500ms 到 400ms 而已，结果并不那么高性价比。

因此咱们必定要时刻清晰本身优化的目标，时刻考虑 投入产出比，在有限的时间作出比较高的价值（若是有空闲时间固然能够尽情干到底）

欢迎各位大神指点交流, QQ讨论群: 258498217
转载请注明来源: http://www.javashuo.com/article/p-zsagomam-do.html