-
-
Notifications
You must be signed in to change notification settings - Fork 203
GraphQL Endpoint is Very Slow #1297
Comments
I have the same problem. With queries on the same collection, on top-level fields:
Unfortunately I have no technical information to enter. Tested on custom docker implementation on aws ec2. |
Directus generate GraphQL schema on each request. To generate schema we need to traverse all the relationship. To make it faster, I am suggesting to use Cache on server-side as well as client-side. For the server-side caching, Please take a look at https://docs.directus.io/advanced/api/configuration.html#config-file-options |
The schema shouldn't change often once in production mode (I still think we should have a system flag for when the schema is "locked"), I feel like the API should cache that and just fetch data. We should definitely look into what info we can fetch once and cache to speed things up. |
Why not trigger the graphql schema generation when there is a change to the structure? |
Well we aren't always aware of a schema change, since Directus uses "database mirroring" admins can technically work directly in the database (not always through the API). So we would have to occasionally check the schema for changes. But this is essentially what I mean by "locking" the schema with a flag so we know when it's safe to cache the schema. |
You're right! Otherwise i tried to enable the caching option, but unexpectedly the cache only works for that exact graphql request, just change it slightly and those 7/8 seconds are back. |
@benhaynes We can add the GraphQL schema caching once we have schema flag. |
Maybe i find a bug that prevents a collection to be cached in the same request, don't cache the whole schema but make GraphQL schema generation faster: !1354 Please try it and let me know if is ok! |
I agree with this. Closing this on the reference of #1354 |
Tested both on your demo api and on a dedicated vps freshly installed with the latest version (no docker). For a simple query (no joins, filters, etc.), the time is always >1s.
Is this a known issue?
The text was updated successfully, but these errors were encountered: