3 ms·
For a point of comparison, when I was using graphql-js around 3 years ago, I was benchmarking things pretty carefully and the main bottleneck wasn't graphql-js
by andrewingram 7y ago
For a point of comparison, when I was using graphql-js around 3 years ago, I was benchmarking things pretty carefully and the main bottleneck wasn't graphql-js -- I had comparable (or faster) response times to equivalent existing hand-crafted JSON endpoints.
But if you're fetching a lot more data than you need for a typical UI, you might run into bottlenecks.
- foota 7y agoYeah, it sounds like the poster is having issues with their deep hierarchy causing lots of unnecessary object creation? I'm still surprised it had that much overhead though, as I generally think of node as being relatively competitive with Java outside of heavy computation.
- 83hajfjeijg 7y agoA deep hierarchy? 3 levels? Really? Lots of unnecessary object creation? We're talking about a total of 1600 fields. If that's considered a lot then GraphQL is in worse shape than I thought.
- andrewingram 7y agoDeep queries aren't usually a problem as it's usually just waiting on I/O, it's wide queries that are a bigger concern. I just remember that CPU load was very low compared to other metrics, so I mostly focused on fixing memory (which was related to the file descriptor issue) usage. One issue I see a lot of (which happens to be part of the problem in this case) is people overfetching data on their list UI (e.g. search results) so that the detail page data is already in the client side store. But this is usually a premature optimisation and ends up causing more problems than it solves.