Cutting a 37‑Second API Call to 1.5 Seconds with Python Flask Profiling

Background

Our business platform’s settings page was extremely slow, taking up to 36 seconds to load, which was unacceptable for users.

Finding the Problem with Chrome

Using Chrome’s Network panel we observed that a simple request for a project with only three records still required 17 seconds, with 17.57 seconds spent in the Waiting (TTFB) state. TTFB (Time to First Byte) reflects server‑side processing time.

Profile Flame Graph & Code Analysis

The backend is a Python + Flask service, so we generated a profiling flame graph to locate hot spots.

First Wave Optimization: Redesign Interaction

The original code created a thread for each gid to fetch CPU‑max values, leading to high thread‑creation cost and unnecessary data retrieval.

def get_max_cpus(project_code, gids):
    # ...
    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

Issues identified:

Frequent thread creation/destruction incurs large overhead.

The CPU‑max value is not a real‑time metric and often unnecessary.

Solutions:

Change the UI so CPU‑max data loads only on user request.

Remove the multithreaded implementation.

Second Wave Optimization: MySQL Query Improvements

Profiling showed that utils.py:get_group_profile_settings caused heavy database load. The original code queried the database inside a loop, issuing one query per gid:

def get_group_profile_settings(project_code, gids):
    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()
        # ...
    return profile_settings

Problems:

No batch query – each gid triggers a separate request.

ORM objects are repeatedly created, adding overhead.

Repeated attribute lookups (e.g., getAttr) inside the loop increase cost.

Optimized version batches the query and moves the filter outside the loop:

def get_group_profile_settings(project_code, gids):
    ProfileSetting = unpurview(sandman.endpoint_class('profile_settings'))
    session = get_postman_session()
    query_results = session.query(ProfileSetting).filter(
        ProfileSetting.name.in_([project_code + ':' + gid for gid in gids])
    ).all()
    profile_settings = {}
    for result in query_results:
        if not result:
            continue
        gid = result.name.split(':')[1]
        profile_settings[gid] = {
            'tag_indexes': result.tag_indexes,
            'interval': result.interval,
            'status': result.status,
            'profile_machines': result.profile_machines,
            'thread_settings': result.thread_settings,
        }
    return profile_settings

Optimization Results

After applying both waves of changes, the same API’s response time dropped from 37.6 seconds to 1.47 seconds.

Takeaways

Key lessons include:

Eliminate unnecessary features when possible.

Reduce the frequency or complexity of required operations.

Use profiling tools (e.g., cProfile + gprof2dot for Python, pprof + go‑torch for Go) to pinpoint real bottlenecks.

Original article: https://developer.51cto.com/art/202008/623383.htm