Minimizing startup time #2452
Replies: 5 comments 5 replies
-
|
This is a great question - one that we don't have a great answer on. Most of our efforts have been on making queries cheap and not so much on the schema build. There is a lot of rules in a valid type system but we have not spent lots of time making it faster @andimarek had been discussing this with me of late. If you are an a AWS lambda world, you can cheat by having objects that actually live longer than the Lambda invocation And since a schema tends to be shared across all users, then it's safe to squirrel away. But this is a work around to the fact that Graphql Schema objects an be expensive to build. The larger the number of elements in the schema, the greater the time it takes to create. if you willing to share your schema with us, we would love to access to it. We have a https://github.com/graphql-java/graphql-anonymizer tool that can be used to take a schema (printed) and create an anonymised version. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your reply @bbakerman.
Understood. A common approach when something takes a long time to create, and that time cannot be optimized away, is to build it at compile time and squirrel it away for runtime. Is this an avenue you guys have been considering?
Here is the anonymized schema: https://gist.github.com/rocketraman/065a4a523a094e4e2c0438f4f304c5db. This is going to grow significantly as well -- we are still relatively early in the development of this project.
I'm using Cloud Run, not AWS. As far as I know the only solution there is to specify minimum instances as 1, so that there is always one warm started instance. This has cost implications, and it doesn't solve the cold start issue when scaling to handle spiky loads. |
Beta Was this translation helpful? Give feedback.
-
|
See PR #2453 PR #2454 |
Beta Was this translation helpful? Give feedback.
-
This I find VERY surprising. This is a simple object allocation and build - there is no code other that field sets here that I can see. I would love to see more perf information on this. |
Beta Was this translation helpful? Give feedback.
-
You're right -- my timer was setup incorrectly, and I was basically double-counting the time taken to generate However, that 1.5s is still huge, and only going to get longer. Overall, if I want to experiment with reducing my schema generation time, I was initially thinking a mechanism in or with graphql-kotlin to cache the results of the schema generation -- but the authors there suggested [2] they can't really help with that and that's something graphql-java has to support. I see PR #2454 makes |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I've confirmed making What I'd really need is a way to serialize and restore |
Beta Was this translation helpful? Give feedback.
-
|
So I think graphql-kotlin used a code first approach - that is you define a
schema in code not SDL strings
So it seems that their "discovery of the appropriate code" is really slow,
especially if GraphQL.newGraphQL(schema).build() is taking only 12 ms.
What I'd really need is a way to serialize and restore GraphQLSchema
itself.
nominally you can print it to string and parse it back in - we found
parsing is 50/50 on schema gen so that is like 24 ms. HOWEVER your in
trouble because the backing DataFetcher code is now probably all wrong and
wired up incorrectly.
You might want to move away from code -> schema if its too slow
…On Thu, 15 Jul 2021 at 07:06, Raman Gupta ***@***.***> wrote:
Yes, I've confirmed making TypeDefinitionRegistry does not help my use
case because graphql-kotlin generates the types from code, and does not use
TypeDefinitionRegistry.
What I'd really need is a way to serialize and restore GraphQLSchema
itself.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2452 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMVWSI6PPNKFVPUORSBRQTTXX34RANCNFSM5AHSMR7A>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Looking into graphql=kotlin - it uses class scanning to find classes that it should turn into graphql types etc.. There are fast class scanners out there (and the one it uses https://github.com/classgraph/classgraph is fast) however with enough class scanning its ALWAYS going to be slower than NOT doing that especially if you have a big schema Yours is a 500 line schema which is while not tiny is not small. So I would suggest the Kotlin class scanning approach here is problematic. Which in a classic compute environment is not a problem - the cost is amortised over many requests - but in a serverless world - its bad |
Beta Was this translation helpful? Give feedback.
-
|
@bbakerman some more performance question here: To get the data from pojos in datafetcher results, you use dynamic java reflection. Does it make sense to speed this up too? Maybe to create on compile time special classes, which access the pojo, so that we dont need the relfecation on runtime? |
Beta Was this translation helpful? Give feedback.
-
|
The Property DataFetcher does use reflection. Reflection in Java is not as
slow as some people think. Slower than direct method access but not an
order of magnitude slower.
Also it has a JVM wide cache to the methods so that once it has been
called, its holds the methods needed for that data fetcher and hence its as
fast a code method invocation.
Your challenge is that in a Serverless world, you are not amortising any of
the costs across requests.
You can however write your own data fetchers that called `pojo.getName()`
direct. This is more than just allowing a `name` field ot be a
reflected PropertyDataFetcher call but its faster.
The question I have is - does graphql-lkotlin allow you to inject your own
data fetchers - I dont know
…On Sat, 17 Jul 2021 at 00:09, knotenpunkt ***@***.***> wrote:
@bbakerman <https://github.com/bbakerman> some more performance question
here: To get the data from pojos in datafetcher results, you use dynamic
java reflection. Does it make sense to speed this up too? Maybe to create
on compile time special classes, which access the pojo, so that we dont
need the relfecation on runtime?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2452 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMVWSLNRHX7UDYKQK6HUXDTYA4SZANCNFSM5AHSMR7A>
.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm trying to minimize application startup time (serverless environment).
I'm finding about 75% of my startup time is currently dealing with GraphQL initialization. Approximately half of that is generating the
GraphQLSchemavia graphql-kotlin and the other half of that isGraphQL.newGraphQL(graphQLSchema).build().What are my options to reduce my startup time? Currently GraphQL initialization takes about 3 seconds -- I'd like to get it down to less than half a second if I can. One thought I had was a way to serialize a
GraphQLobject once at build-time, and deserialize it at runtime, but the object is not Serializable.Beta Was this translation helpful? Give feedback.
All reactions