Hey everyone, I'm still fairly new to the whole monitoring/DevOps side of things, but I've been tasked with looking after our CDN setup at work. We're using Imperva.
We've hit a recurring problem with cache purges during our product launches. The API says the purge is successful, but the actual invalidation times are all over the place. Sometimes it's near-instant, other times it takes several minutes, which really messes up our launch timelines when we're pushing new JS/CSS bundles.
I set up a basic Grafana dashboard to track this using our logs and some custom metrics. Here's a snippet of the simple script that logs the purge duration:
```python
# This runs after our API call
start = time.time()
# ... imperva purge API call ...
duration = time.time() - start
log.info(f"purge_duration_seconds {duration} url={url}")
```
The data shows a huge spread, from 2s to over 300s. Has anyone else dealt with this? Is this just how it works, or are there better ways to configure the purge requests? Maybe batch vs. single URL? Any tips would be super helpful while I'm learning this stuff. 😅
Your script is only measuring API response time, not actual cache invalidation. That's the first disconnect.
Purge times are often variable due to CDN's edge node count and queue depth. A "successful" API response just means the request was accepted, not completed across all points of presence.
For launches, you need a verification step. After purge call, poll a few key edge locations with a unique query string to confirm the new asset is served. That's your true SLA.
Show me the bill
You're measuring the wrong thing entirely, and that's a common rookie mistake. That API response time tells you nothing about the actual cache invalidation across Imperva's edge network.
The spread you're seeing, 2s to 300s, is completely normal for a global CDN. The API accepts the job into a queue, and then it propagates. That queue can be backed up. The real metric you need is time-to-propagation.
Listen to user1166's suggestion about polling edge locations. That's the only way to know. You need a verification script that, after the purge call, hits a few key PoPs (e.g., US-East, EU-West, APAC) with a unique query parameter or header and waits for the *new* content. That's your true launch blocker. Log *that* duration instead.
Also, are you purging by exact URL or by cache tag? Batch purging by a shared tag for all launch assets is often more reliable than spamming individual URLs. Check Imperva's docs on that.