Site Performance and Resource Usage
This page covers site-wide resource usage — CPU, memory, disk, and database growth. If the specific symptom is feeds loading slowly, go to Slow Feeds or Feed Loading Errors instead, which is narrower and more likely to have your answer.
What Actually Costs Anything
Benecaster’s normal running costs are lower than people expect, because the two heaviest things in podcasting don’t touch your server:
- Audio is never served by WordPress. Feeds point at your podcast host’s URLs. Your bandwidth isn’t involved unless you enable the download proxy.
- Feeds are cached per tier, not per subscriber. 500 subscribers across 3 tiers means 3 cached documents. A feed request is a token lookup plus a cache read.
So when a site running Benecaster is genuinely struggling, it’s usually one of the three things below rather than feed traffic.
1. The Download Proxy
This is the single biggest load Benecaster can add, and it’s opt-in.
With the proxy enabled, every episode download passes through WordPress before redirecting to your audio file. A show with a large active audience and frequent releases can generate a lot of PHP requests that wouldn’t otherwise exist, and each one writes a log row.
Check: is the proxy on, in Benecaster → Settings? If your site slowed down noticeably after you enabled it, you’ve found the cause.
Options: turn it off — you keep full feed and subscriber analytics without it, losing only per-episode download counts. Or keep it and give the site enough headroom to carry it. See Download Tracking for exactly what you gain and lose.
2. Log Tables Growing Unbounded
Two tables grow continuously on an active site: the download proxy log and the feed request log. Neither is large in absolute terms — a 5,000-subscriber show generates on the order of 100–150MB of proxy log per year — but an unbounded table on shared hosting with a tight database quota eventually becomes a problem.
Check: Benecaster → Settings → Tools → Analytics Data shows row counts.
Options: set a retention window, which enforces automatically via a nightly job, or use Prune now for immediate cleanup. Both preview the row count and disk space before you confirm. The feed request log can also be set to record failed requests only, which keeps the useful re-engagement signal at a fraction of the write volume. Reducing Disk Usage walks through every lever.
3. No Object Cache at Scale
Without Redis or Memcached, cached feeds are read from the database. That works, and for most sites it’s fine. At larger subscriber counts it means database reads on requests that could have been memory reads.
Check: does your host provide Redis or Memcached, and is a persistent object cache plugin active?
Options: enable it if your host offers it — Benecaster uses it automatically through WordPress’s standard caching functions, with no configuration. If your host doesn’t offer it, that’s a reasonable prompt to look at hosting once you’re past a few hundred subscribers. See System Requirements for guidance by audience size.
Narrowing Down a Slow Site
Before assuming Benecaster is the cause, establish whether it is:
- Deactivate Benecaster briefly on staging and re-measure. If the site is still slow, the cause is elsewhere.
- Check your host’s resource graphs. Most managed hosts show CPU and memory over time. Match the start of the problem to something you changed — enabling the proxy, an import, a plugin update.
- Look at what else runs on the site. Benecaster shares the server with every other plugin. A slow site running Benecaster isn’t necessarily a site made slow by Benecaster.
Bulk operations — imports, migrations, bulk enrollment — are genuinely heavy while they run and settle afterwards. If the slowdown coincides with one, let it finish before investigating.
When It’s Cron, Not Load
A site that seems fine but where scheduled things happen late — emails queued but not sending, expirations not processing — isn’t a performance problem. WordPress’s cron waits for incoming traffic to trigger it, so on a low-traffic site it runs late regardless of how fast the server is.
See Cron isn’t firing on time.
Still Struggling
If none of the above accounts for it, Known Plugin Conflicts covers interactions worth ruling out — caching plugins in particular can cause symptoms that look like performance problems but aren’t.