The Executor fires an OperationEvent at the start of a GraphQL operation and at the end of a GraphQL operation. This makes it easy to track queries that are being executed and collect information about them. However, when a GraphQL query is cached then no events are fired which means that cache hits can not be tracked.
There are possibilities for workarounds by using Kernel subscribers and looking at raw HTTP requests, but these provide a lot less information than the GraphQL module can provide and introduce a bunch of global state to deduplicate things.
Fire an event when a GraphQL request is served from the cache. This makes it trivial to implement tracking of cache hit rate or other GraphQL API access patterns.
GRAPHQL_OPERATION_CACHE_HIT with value graphql.operation.cache_hit is added as new constant to OperationEventgraphql.operation.cache_hit event is triggered receiving an OperationEvent instance with context and result| Comment | File | Size | Author |
|---|---|---|---|
| #2 | graphql-3567493-2.patch | 1.09 KB | kingdutch |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
kingdutchAttached patch should work for 4.x and 5.x seeing as the classes involved have not changed between versions.
Comment #3
tbsiqueiraComment #4
klausiThanks, can you make a drupal.org merge request so that we see the test and lint cases run?
I think this should be ok to commit and invoking an event should not be much overhead. However, if your only goal is to do profiling then I would rather like to see a graphql_profiling submodule. That module can overwrite the Executor and inject events for profiling, or even do some profiling itself. With a submodule there is zero impact on the normal prod module. Then we could also add more profiling events, like which dataproducers are called and how long they execute.
My ideal goal would be to profile a full frontend request that makes multiple graphql backend requests. It should help you figure out which graphql requests are slow, what the queries involved are and which parts of the query are slow.
Comment #7
kingdutchI've created a MR for both 4.x and 5.x
Comment #8
klausiOK thanks, I'll leave the merging to you :)
on 8.x-4.x phpstan is failing, can you also take care of that? It probably runs on Drupal core 11.x, either we can update the code in those fails or make phpstan exceptions otherwise.
Comment #10
kingdutchMerged both MRs and opened #3575931: Fix PHPStan warnings on 8.x-4.x to track the PHPStan warnings :)