Part of my NextJS project consists on grabbing paginated/iterating data from an api using axios and saving in a Postgres db using Prisma to further manipulate them.
I think it is important to mention I’m trying to keep my server code as close as possible to a clean architecture, which means the touch point between Client and Server, through the actions folder is where the injection happens.
With that said, I’m experiencing something I don’t understand and I would love thoughts about that.
Having 2 Serverless Functions, 1 to grab data and 1 to save data, they are called several times from the client - around 200x - with a sleep between calls to avoid api limitations. What happens to them is a sequence of calls that start with an acceptable response time and it keeps increasing for the next ones until they reach max response time and everything fails.
Why is this happening? I’ve never seen something like that in other services and I’m wondering if someone could give me a clue about Vercel’s service.
On the screenshots the log at 23:54 says the execution duration took 7.99s and 5 minutes later at 23:59 the execution duration took 8.18s - Difference is minimal, but this is to demonstrate what is happening as I could not get the logs from earlier time where it started with a fair 1s execution duration.
As I understand: you’ve two API endpoints that take ~1 seconds to execute but over time (as you make more and more calls) it gets slower to ~8 seconds?
To help debug this and figure out how to resolve:
Can you shed some more light on what is happening inside the code apart from saving and reading the data?
Have you tried measuring the time between different statements inside those API? For example, it could be that the database response is getting slower.
Which database provider are you using (Supabase, Neon, etc.) for Postgres?
Hi Anshuman,
Thanks for your reply and welcome message.
You are right about the whole concept, one thing though is I’m not using the API folder instead my all my serverless functions are in src/actions
At moment, the code in the client is a for loop iterating over an integer value which corresponds to a page number of data to grab. With the page number, it calls the Serverless Function to grab data from an external API through axios and it always returns an array value - it breaks the for loop when the returned array is empty. With the array value returned I then call another Serverless Function to save that returned value already treated in DB. When in development, I also includ an await sleep function in the for loop to avoid breaking the external API requests/second limit.
The database I’m using is Neon Postgres through Prisma ORM.
The problem seems to be with the Serverless Functions themselves because it increases the execution time both for the external api call and the write to DB. The server actually abort the connection due to reaching its limit with the external api call as the writing to db function always is faster.
Including more screenshots of the logs.
The first one is from the local server logs. Although db write speed cannot be taken into consideration the screenshot was taken to show that calls are kinda stable among pages. The one taking longer is the one that calls an external api for data.
With the same code, the other 2 screenshots are from server logs. The one that logs the page number is the function that calls an external api for data, being followed by a function call that writes the data to db. Functions gradually add time to their execution until reaching its limit. On page 12, executing time was already increasing over each step but they were okish, while on page 85, the writing time was 3.47s and the page 86 pulling execution time was at 8.08 seconds, right before breaking.
Hi @titica, thanks for sharing the details. It helps me understand the issue better.
From the server logs screenshot, I can’t make up the response times for the external API. Can you try and compare the specific request times as you did during the local tests?
Because serverless functions shouldn’t be slowing you down, that’s exactly the opposite of what they do—they scale as much as the load.
Can you share what is the external API in question here?
I don’t know what I have to do to get that. I’m not sure, for example, if getting the timestamp before the axios call and afterwards to calculate the response time is a best practice.
Anyways, I would like to emphasize the increase in execution time is not exclusive to the external API call. It is happening with the write to the DB as well.
Hi @titica, thanks for sharing this information. I think the regions are close enough, so the latency shouldn’t be a problem.
A few more questions:
Have you tried deploying a simple function that doesn’t need the database or the external API? If not, I’d recommend creating a simple JSON response endpoint to validate if the issue persists there as well.
Did you notice a change in this pattern with any recent deployments? Or was this always the case ever since your deployed this app to Vercel? Asking to see if any recent code changes such as a new library brought the issue along.
I changed the approach on how to grab data from the external api. I now ask the user to export a csv from a third party site and upload it in my app. Although the execution time of calls to write in the DB fluctuates a lot (from 1.2s to 11.7s) , it is not a consistent increase like I was seeing before. Then I decreased the quantity of objects I send in each loop to write in the DB and raised the execution time limit to 16s - just to leave the app in a “working state”, although not optimal.
I’ve read Prisma adds a good amount of overhead in DB operations. To debug that, I would need to rewrite more code to check the weight of Prisma overhead and Vercel’s serverless functions in overall execution time. And if rewriting code is needed, I shall be moving out from Vercel and Prisma completely to a platform I better understand its behavior and what to expect. Anyways, still to be decided as I’m definitely not in the mood to rewrite working code.
I appreciate your attention to it and I would love to contribute with the Vercel platform. I can even share the repository in case someone is interested to investigate it further.
