Add example configuration for a caching Varnish server#91
Conversation
|
Why would you add varnish instead of reducing the polling rate in the integration? If the data is cached it will be stale and creating a data point with stale data is just deceptive. Might as well just lower the polling rate, get fewer data points but know that they are fresh and accurate. I lean towards not adding this, perhaps the polling interval needs to be better called out in the docs around the warning? |
|
Hi, just checking on this |
|
Oh sorry, didn't see the previous notification. The two biggest advantages to using a caching proxy are safety and concurrency for multiple collectors. If HA is the only thing on your network polling the PVS and you're not playing with it yourself, direct access would be fine according to the solar data update interval. But in my case I have both HA and an otel collector polling it, so a proxy ensures multiple sources aren't adding up to more frequent hits on the PVS. Plus, when I'm debugging e.g. my own poller, I have a tendency to spam it with With regard to staleness, I'm not too concerned with it being up to 5 minutes stale, especially since the upstream's data seems to be an even worse offender (especially for the consumption metrics I've noticed). To be clear, that Varnish config will not serve cached data forever if the upstream completely fails, only up to the 5 minute TTL, after which it will serve a 502 IIRC. Not a big deal if you don't want to maintain that documentation; like I said, it works for me and I mainly wanted to announce it... somewhere for posterity sake. |
I've had good results with using Varnish to cache the output of my PVS6, but it required some aggressive cache-busting configuration, so I figured this would be a good place to document it. Thanks for the great integration!