Open oliver-sanders opened 9 months ago
Early investigations using https://github.com/cylc/cylc-uiserver/pull/546:
cylc.flow.network.graphql.IgnoreFieldMiddleware.resolve
and it's callchain.iscoroutinefunction
called here took a reasonable amount of time, it's possible that upgrading our dependencies may remove the requirement to check for synchronous functions?ensure_future
call (now deprecated), which calls create_task
which took a whopping ~15% of the CPU time in my example.to_snake_case
__hash__
'able opening the door to caching.The promise
is gone when I get around to (hopefully soon) upgrading Graphene, and rewriting our own graphql-ws
(as this uses promises too) ..
It appears, promise
was created by the original developer of Graphene who (I assume) also (in addition to async support) found it a useful way of translating graphql libraries of javascript to python equivalent (could be wrong)..
The other thing we do is recursively sift through the GraphQL query result (in the middleware) and strip out all the null fields... Not exactly sure how expensive this is.. Think I use the promise library for this.
to_snake_case
This simple method gets hammered (10's of thousands of calls).
Sorry if I've missed relevant discussions elsewhere (just back from leave) - but can we just rename all affected variables using JS conventions? It'll look ugly in a Python program, but the payoff sounds big.
We could, but it would be easier to just cache the output of the method or re-write the code so that method doesn't get hammered, there's a separate issue for this in cylc-flow.
This workflow has proven to be remarkably difficult for the UIS & UI to handle:
For more information see: https://cylc.discourse.group/t/slow-load-of-cylc-workflows-disconnects/823/19
Investigation so far has confirmed:
This issue focuses on the UIS side of things.
Suggested remediation (Flow/UIS only, please update with new suggestions):