Queries result in abnormal requests p/second

Hi,

For starters, we’re relatively new to MongoDB, and Apollo GQL by extension - so any help is appreciated.

We’re building a page using React with MongoDB Realm. We’re using the GQL endpoint via Apollo GQL.

We’ve hit a roadblock as after ~30mins of use the page maxes out our tier (M2) and throttles us. We’re aware of these limitations, however we don’t think we should be hitting them at all.

Our database is quite small ( under 100MB ) filled with dummy data. So we’re baffled how we’re hitting our limits.

The page in question is essentially just a table with a dropdown. You select an item from the dropdown and it updates a few state variables then pings off a lazyQuery (see img1) to the server based on the value you selected.

It works ok, judging by vigorous logging we can see we’re only triggering the useEffect hook (which fires the query on value change (see img2) ) once per dropdown change. This is expected.

What isn’t expected is our metrics tell us we’re hitting 100 -150 requests per second which presumably is sucking up computing time / server load and causing the throttling (see img3).

We’ve also got a page which fires a simple query for small data, there are stateful changes on the page but none that interact with the data itself. Once the data is fetched we can use it from cache successfully but the initial network request still fires twice according to our MongoDB logs ( see img4 ). We presume this is the same issue as the other page on a smaller scale.

What could cause duplicate queries to fire? How individual queries end up causing such a huge load? We were thinking it could be a side-effect of having queries with relationships to other collections, and each trip through a relationship is another request - this would add up quickly with how our database is structured.

Any help is appreciated, we’ve read through docs (may have missed something) and searched high and low for an answer but found nothing. Advice on troubleshooting and so on is also appreciated.

Cheers,

Alex

P.S. Apologies for the horrific paint collage - I wasn’t able to upload individual images.

Hey Alex - thanks for reaching out. If you’re still facing this issue, do you mind providing a bit more information on your Realm app? Specifically -

  • Providing your Realm URL (only employees will be able to see your app)
  • Some examples of request ids of the duplicate requests on the Realm Logs

Can you also log all outgoing requests and paste them here from the client and paste them here? This will narrow down whether there might be something going on in the client or server side.

Hi Sumedha,

Thanks for getting back to me.

We’re currently not experiencing the issues on the larger page. However we are definitely experiencing duplicate requests - made even more evident by logging the apollo requests (attached).

As for not experiencing the overload, we usually don’t experience anything until after some fair use. The issues we faced were on 29/06/21 @ 12:30pm - 1pm.

Sorry for the ignorance, but what do you mean by Realm URL? the GQL endpoint?

As for duplicate requests here’s two IDs from just a moment ago - the ones in the image of the requests.
First Request: 60e62a3d59a8cc572e706b37
Second Request: 60e62a3d901e466e2004493d

As for logs, hopefully these apollo request logs will suffice?

Smaller page (duplicate requests being logged) are on the left

Larger page - sending one request on initial load as expected - is on the right

We’re going to continue monitoring the larger page, as before it would be fine for a bit but throttle us quickly.

The app url would be great (looks like this - App Services)

If I’m reading the image right, it seems like the duplication is happening on the client. Is it possible that something is going on in the apollo client implementation that is logging the duplicate request rather than an issue in Realm?

Hi Sumedha,

Thanks once again for the response, and apologies for the delay in reply - I’ve been away, and very busy!

We started delving deeper into the queries repeating themselves, and in turn discovered a couple of solutions to some of the issues, as well as presumed reasons for the abnormality in queries.

In case this ticket is found later down the line, here’s what we discovered:

Duplicate queries being sent from client
Problem: Initial renders would fire two or more identical queries one after the other despite nothing expressly telling it to do so
Fix: Apollo is known to re-fire queries when data is changed within them (variables, query, etc.) by changing the useQuery to a useLazyQuery, moving it into a useEffect with no dependencies and moving any dynamic data (in our case some query variables) into the lazyQuery’s callback it has fixed this problem.
Notes: Interestingly this is how the larger of our pages work by coincidence, and that page never experienced this issue.

Newer issue: Clicking on a button to fire a lazyQuery would repeat all other queries fired beforehand
Problem: Similar to the above, lazyQueries would re-fire if a different button was clicked
Fix: As this is a query fired from a trigger, rather than a render, we utilised the useApolloClient hook, and ran the query within the onClick attribute using the client object. Here we could async/await and run the onCompleted code outside the query after data has returned

Large/abnormal sets of requests per second
Problem: Using a page with several queries on it would soon throttle our service after some heavy use
Fix: We’re unsure if we’ve definitely fixed it. But after discovering Apollo re-firing queries when data changes we think there was a link between that and having the lazyQuery callback in the useEffect dependencies. We think Apollo re-fired the query when the query changed, which triggered the useEffect as the query has changed, which fired the query again, effectively doubling or tripling requests. Removing the callback from the dependencies seems to have solved it.

We’re monitoring the last problem as we go, but so far so good.

Thanks for your assistance and I hope our discoveries can help others.

Cheers,

Alex

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.