Endpoint performing 10X slower in production

Erin

Hi!

I have an endpoint that takes less than 5 seconds in "Run & Debug", but now that I've published it, it's taking more than 50 seconds when my front end pings it.

To test, I've copied the exact input data from the logs, opened the endpoint using the link from the logs, and used "Run and Debug". The logs that show >50 seconds to execute are always taking <5 seconds in "Run & Debug" this way.

This is a new one for me. Any thoughts?

Erin

It was user error! I had failed to save a change to the add-on. Thanks again to everyone who chimed in. You're good people :)

Pawel Magdanski

I've encounter such situation before, what is your CPU usage at the time when it happens? Is that slowdown constant?

Erin

The slowdown has been constant for that endpoint. It has come in >50 seconds on a dozen or so calls I've done over the past hour. All other calls are coming in at their usual speeds. Here's a screenshot of my computer's performance when I hit the endpoint:

Doesn't seem like anything unusual. However, I don't know that my CPU should matter since it's not an issue of loading into the front end—it's an issue of the processing on Xano's servers…right?

Erin

I have a hypothesis. This change to the back end also requires a change to the front end to display the data. I'm having a hell of a time because everywhere that a single hour's worth of data is supposed to show, it's showing me the whole day's worth of data.

That paired with the exceptionally slow processing time is making me wonder if there's some kind of bug in how it saved/is executing my function and if it's processing way, way more data than it should. (As in returning the whole day's data when it's supposed to do only an hour's worth.)

Again, it's functioning and performing just fine in Run & Debug, so it might have something to do with publishing…? @Michael Udinski I'm out of my depth here. Any thoughts?

Erin

In case you guys poke around, I've changed the endpoint back to the original, but all you need to do to test this bug is hide the potential_datetimes function (step 2) and unhide the potential_datetimes_by_hour function (step 3).

Pawel Magdanski

@Erin Hi Erin, I meant the CPU usage of your instance, but if other endpoints are not affected with a slowdown it might not related to CPU usage

Ray Deck

Two ideas:

1) Is your front end asking the same questions as your run-and-debug tests? One way to evaluate is to take the "input" from the request history (there's a button the right to copy it) and paste it into your run-and-debug inputs. That might give some insight - do the same inputs generate the same performance or outputs?

2) How many front-end calls are getting made? Again, looking at the request history to see how many requests per minute are coming through. The system is designed to only accept so many of them at once. If you are flooded (and flooded is at different levels depending on the speed of the endpoint and size of your Xano instance) you can get a backup, which leads to nontrivial delays.

Erin

@Ray Deck

Great questions.

1. Yes, I used that input copy button from a log that was >50 seconds and it came in under 5 seconds in "Run and Debug" :(
2. I had a look, and the most calls I had when this issue was occurring was 4 calls in one minute. That seems like it should be manageable…

Erin

I just tried using the input data from one of the logs on my Swagger documentation, and it was soooo slow it wouldn't even return. (I was hoping it would prove/disprove my theory about it returning too much data. Didn't get the data back to see though.)