Closed schneefux closed 7 years ago
Hey @schneefux looking at this, I think perhaps you're causing a timeout with this query (not your fault). Essentially you're causing a giant cache miss, looking for data within a time period that doesn't exist. I think if you limit your queries to the last 120 days (per data retention ticket) you'd see an improvement. Mind trying and letting me know?
Aha! Sure, will do. The 504s are 2017-02 until 2017-04, so this makes sense. You mentioned it in #222. In the changelog it is (continously?) "upcoming", so I was not aware that this change is live already.
Ok - so the issue here is that querying outside of the retention period, causes a giant cache miss and slows things down. We should validate that parameters are within the retention period.
I believe this is resolved, but we want to hold the ticket open because we think that the API should return an error if querying outside the retention period.
Fixed!
We're seeing a very high rate of 504 since about a week or two ago. Here are a few recent log entries from requests that failed at least two times. The first column is the process id (irrelevant), the second the service name (irrelevant), the third is the log's timestamp (when the error occured), then follows the debug message (only
API error
s here) and a key value pair of paramaters of the request and the response (status
anderror
).You can write curls from it as-is, for example for the first log entry:
This request failed with 504 everytime I ran it.