Gcloud cdn - cache hit ratio unclear

0
votes

I'm using google cloud cdn (Load balancer with a backend service) and the hit ratio status is not very clear.

In the image below you can see:

Left image - CDN view - Value of cache hit ratio is "n/a".

Right image - Backend service view - upper part (in green) - I see some responses which are served from cache - 0.6 RPS.

Right image - Backend service view - lower part (in red) - Cloud CDN cache hit is 0.00 RPS.

enter image description here

Can somebody help me to understand the differences between the 3 places?

And what is my current cache hit ratio?

1
google-cloud-platformload-balancinggoogle-cloud-cdn
Can you provide more informations about how the load test is made? Graphs on my projects works well but I have about 50 requests/s. – Yann C.
A simple curl with 1000 in parallel. – RtmY
So, how long does your test takes? How many requests per second are sent? – Yann C.
After performing the 1000 calls to my server , the chart (green arrow) is being updated (after a few minutes) with a RPS 0f 0.6 from cache and 0.00667 not from cache. But this value is not reflected on the 2 other places above (red arrow and red question mark). The value of these places never changes. – RtmY
Try at least a 10 min test, I think there is not enough data as @elving says. Calculus are pretty difficult to make with +90 edge locations and the need is not to log every request on the graph. I think they are using an average with at least 1 min interval and they aggregate data over all the edges. Personally, I love github.com/tsenart/vegeta for my load tests, curl is for debug, not for load testing. – Yann C.

1 Answers

6
votes

Cache hit ratios are necessarily computed over some interval of time. The cache hit ratio column in the Cloud CDN origin list shows the ratio over the past couple minutes. In your case, it shows n/a because there were no cache lookups in that time period. The Frontend Location diagram on the Backend service details page similarly shows the ratio over the past couple minutes. In the backend service time series on that same page, you can see how the number of cache hits and misses varied over time.

It's not meaningful to talk about cache hit ratios when a service isn't getting any traffic. Once your service starts receiving traffic, you can use the cache hit ratio to understand what fraction of that traffic is being served from cache. All these metrics are delayed by at least a few seconds; it will take some time before a particular cache hit or miss is reflected in the UI.