Initial data #106
Initial data #106
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| currentPageNumber === 1 | ||
| ? undefined | ||
| : POSTS_PER_PAGE * (currentPageNumber - 1), | ||
| }) |
There was a problem hiding this comment.
How long does this query take? If it's slow, we should fix the query before caching it.
There was a problem hiding this comment.
It's coming in about 490ms, so pretty long...
There was a problem hiding this comment.
Great info. I checked insights and this query looks like it's max taking 5-10ms. Which is slow for that query & data size, so can likely be optimized. But that's not the source of the 490ms.
Next places to look:
- Where is the server vs db? Is it network latency?
- How is the connection established? Is there anything in prisma in between?
There was a problem hiding this comment.
Great, I'll keep digging in, get it fixed up.
There was a problem hiding this comment.
Beam's DB is located in us-east-1:
The Vercel functions are in iad1
There was a problem hiding this comment.
@ayrton @mscoutermarsh I've done a fair amount of work here to try and get this faster, and have also improved some of the UI using the initial data.
On the query latency, I'm not seeing anything happening on the Prisma end that would lead to higher latency like this; in some testing, caching the query calls seemed to have done quite a bit to improve load times across the board (176ms). Overall, the Prisma and data implementations are exactly the same as the old one, but in the 2.0 we're getting the data on the server rather than the client, and we're removing loading skeletons, which we had before. Since that would block the TTFB, I think it could be leading to us noticing a slower initial load. Any suggestions for getting this stronger are welcome, I'll try and get them implemented over the weekend.
ReactionButtonto work on the feed route as well.Part of a broader slate of performance work that I'm going to continue doing in the next few weeks.