When implementing a new architecture, it's essential to regularly check your platform's logs and insights. Let’s be honest—nobody gets everything perfect on the first try, and that's okay. The key is identifying issues quickly and addressing them as soon as possible.
Recently, I took a deep dive into our new XM Cloud and Vercel platform, which has been live for the past few months. While exploring Vercel’s Monitoring tab, I stumbled upon a predefined query called Cache Hit Rates. Curious, I clicked on it, and the results were far from what I had anticipated.
Cache Hit Rates – Last 30 Days
The chart revealed that nearly 50% of the requests bypassed Vercel’s cache, meaning they had to be executed by the underlying architecture. I decided to extend the time range from 30 days to 90 days to get a clearer picture.
Cache Hit Rates – Last 90 Days
It became evident that something had been released within the last 30 days, causing a significant increase in cache misses. But the next question was: Which requests were responsible for this cache miss surge?
Since I didn’t have the answer immediately, I reached out to Viktor Atanasov from Vercel’s Customer Success team for guidance on pinpointing the issue.
Since I didn’t have the answer immediately, I reached out to Viktor Atanasov from Vercel’s Customer Success team for guidance on pinpointing the issue.
Clearly something has been release in the before the last 30 days that causes Vercel to have such a huge impact on the cache being missed. So which calls are actually responsible for the cache being missed so many times? I didn't have the answer so I asked Viktor Atanasov, who works at Customer Success for Vercel, how to identify the problem.
Edge Requests: Pinpointing the Problem
Using a Vercel monitoring query, we grouped the edge requests by request_path and limited the results to the top 10 paths. This query provided the following outcome:
Vercel Monitor Query Results
The results clearly highlighted the paths responsible for the majority of the missed cache requests. Armed with this information, we decided to address the route with the heaviest API traffic first.
In our case, we chose to move this API route out of Vercel and directly into an Azure Function. This significantly reduced the load on Vercel.
Why We Made This Change
We had two key reasons for this decision. First, the API route was merely functioning as a proxy to our backend API, which made keeping it on Vercel unnecessary. Second, Vercel tracks the processing time used for the requests, also monitoring the data consumption. With the growing volume of requests, the data usage was on track to become a significant issue."
Final Thoughts
I hope this gives you some insight into how monitoring in Vercel can help identify and resolve issues efficiently. If you're dealing with high cache miss rates or other performance bottlenecks, I recommend exploring Vercel’s monitoring tools.
"Don't be a fool, use Vercel’s monitoring tool—unless you enjoy fires that make servers drool!"
Want to read up on the Vercel Monitoring tool, a good place is to start with their documentation. Otherwise, be sure to request help from your Success manager or create a support ticket if all else fails.
Until next time!