Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

performance issues due to breadth first execution of grapqhl queries in case of async resolvers during calls burst

Open
#200 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
api, backend

Research direction

Start with the issue's asyncio proof of concept and the schema.execute_async entry point, then trace how asynchronous GraphQL fields are scheduled and resolved. Compare that behavior with asyncio's task queue under concurrent queries. Done would require an agreed scheduling or priority approach, demonstrated by the reported burst scenario without degrading execution time or memory use.

Written by the indexing model from the issue text.

Description

When we receive calls burst we found that the calls "wait each other" (i.e. the first call of the burst waits the last one).
This result in degradation of performances in both time of execution and memory consumption in the server because we have to keep many calls in fly.

This is particularly evident in big graphql queries where the users request many fields and we have several depth in the queries where each level has many async fields.

Just to be TLDR, looking the implementations of graphql and asyncio we understood that this is due to the following:

  • graphql breadth first way to schedule and resolve the fields
  • asyncio internal FIFO queue of tasks to be executed

As an example lets have queries like that, where data may be like beer vendors and we want for each beer vendor many fields that describes that vendor, a1...a100, b1...b100, ...:

query {
  data {
    a1 {
      b1 {
        c1
        ...
        c100
      }
      ...
      b100 {
        c1
        ...
        c100
      }
    }
    ...
    a100 { ... }
  }
}

If we have n of this calls coming in burst when we arrive to the depth of the c fields we have many many task scheduled in the asyncio queue.

If we check the of order of execution we have that the first query, on each level, "waits" the other queries, because all the queries schedules a lot of tasks.

In the proof of concept, that you may find at the end of the post, you can verify the order of execution of the resolvers.

It could be very nice to have some sort of priority in the order to let the first query not wait the scheduling and resolve of all the queries before ending.
I understand that this is something between graphql and asyncio but i think it could affect the use of graphql in environments receiving many calls.
Fixes, helps and hints in how to improve this would be very appreciated.

import asyncio

from graphene import ObjectType, Schema, String, Field

FIELD_NUMBER = 2
CONCURRENT_QUERIES = 10


def make_resolver(i, j=None):
    async def resolver(self, info):
        print(f"START query {info.context['query_number']} | a{i} | b{j}")
        await asyncio.sleep(0.001)
        print(f"END query {info.context['query_number']} | a{i} | b{j}")
        return i

    return resolver


def create_fields():
    fields = {}
    for i in range(FIELD_NUMBER):
        inner_fields = {}
        for j in range(FIELD_NUMBER):
            inner_fields[f"b{j}"] = String()
            inner_fields[f"resolve_b{j}"] = make_resolver(i, j)

        MyType = type(
            f"MyType",
            (ObjectType,),
            inner_fields,
        )

        fields[f"a{i}"] = Field(MyType)
        fields[f"resolve_a{i}"] = make_resolver(i)

    return fields


async def make_query(schema, query_number):
    inner_query_values = [f"b{i}" for i in range(FIELD_NUMBER)]
    query_values = [
        "a%s {%s}" % (i, " ".join(inner_query_values)) for i in range(FIELD_NUMBER)
    ]
    query_string = "{ %s }" % (" ".join(query_values),)

    await schema.execute_async(
        query_string, context_value=dict(query_number=query_number)
    )


async def main():
    Query = type("Query", (ObjectType,), create_fields())
    schema = Schema(query=Query)

    await asyncio.gather(*[make_query(schema, i) for i in range(CONCURRENT_QUERIES)])


asyncio.run(main())

Dominant language
Python
Stars
531
Forks
147
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from graphql-python/graphql-core

All issues in graphql-python/graphql-core

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.