Landscape Tiers

Table of Contents

Short Answer Take Aways

The Broken Link Checker for WordPress can be configured to avoid excessive peek-demand on CPU resources and avoid a self-denial-of-service situation; while still providing the desired business outcome for checking content link quality.

1. Never use the ‘Run continuously while the Dashboard is open’ option.
2. Never use the ‘Run hourly in the background’ option.
3. How-To Configure BLC (2.4.1) for a passive business policy; to be server-friendly.
4. Leverage a server side cron job. Do not rely on website traffic to trigger cron.

Long Answer for Detail Adventurers

WordPress server performance is (1) part-art (2) part-science and (3) part-juggling. Finding the balance between them all, while prioritising capability versus financial expense versus the barrier-to-entry learning curve, can be a frustraighting process for WordPress website owners, maintainers and developers.

One extream is to just ban WordPress plugins that are resource intensive and then use marketing messages to convince the hosting customers (website owners) why they are ‘better off for the decision being taken away from them’ if they want to continue using that specific web hosting company.

However, that approach ultimately fails to respect the website end users; you know, the people that the website owner is trying to serve.

Ultimately, there is no right or wrong choice.
Knowingly choose your consequences.

You can use a hosting company that makes you feel safe while limiting your business capability for the sake of an enforced technical philosophy … or … you can use a hosting company that respects your business capability and works with you to enable capability you need to grow your website, at your pace.

Website Content and Broken Link Checker

One aspect of quality website content is the integritity of navigation links.

Introducing the Broken Link Checker (Local) plugin (BLC) v2.4.1 for WordPress.

✅ Leverage your server resources to find broken links in your website content.
✅ Use the convient email report as a reminder to go fix broken links, sooner.
✅ Use a simple list to proactively fix links pointing to missing internet targets.
✅ Minimise support ticket noise from website users telling you about broken links.
✅ Avoid minor brand reputation damage when website users just click away.
✅ Avoid dependency on third-party online services when using Local, not Cloud.
✅ Website owners can be confident that their content links are 99.999% ok.

A website owner can lower the content link-quality risk with broken link checker plugin.

A website owner can choose an aggressive or passive business policy.

Aggressive Business Policy for Link Quality

An aggressive, short life-cycle use of the broken link checker plugin generates a fair bit of redundant server side processing. In turn, that helps to validate the enforced technical philosophy of some web server hosting companies banning specific plugins.

An aggressive use of the broken link checker (local) plugin also raises the minimum hardware requirements for the website owners monthly hosting expenses. Which can be a waste of money when this peek-demand is short lived and the server spends the rest of the day mostly-idle.

This screen shot shows what happens to a single-core CPU host when BLCLP is configured to ‘Run continuously while the Dashboard is open’ in 4 unique WordPress websites hosted on the same server. Ouch …

Despite the server being up and running, for a few minutes, the website user experience gets a bit random and unstable. With an occassional Database Connection error and sometimes a 500 or 502 server error. Ahh, no … the database is perfectly ok.

Either way, the website content is not delivered to the website user … for a short while.

Even worse, most of the server dashboard-style monitoring tools do not clearly show any metric like ‘Count of Undelivered Pages / Requests’; a true reflection metric of the website user experience.

One good hint that something needs to be re-configured is when the ‘Idel CPU’ shows a continuous high-use of the CPU resource.

The next screenshot shows that for approx 3 hours (05:30 – 08:30 am) a website maintainer (cough * me * cough) was performing light housekeeping activities, with heavy consequences. The BLCLP functionality was manually triggered to do a full re-check of all links, and during that time the overall WordPress administration area experience was mostly an un-responsive server … effectively the server was down, from a website user perspective; even though we know it was up, busy and just not talking to anyone else.

Yes, the graph is showing an overloaded server that was the result of intentionally running up to 12 unique domains on a single-host single-core CPU server. No database issues, no traffic throttling issues, no memory issues, ok but high disk & traffic usage (as expected). Just a clogged up CPU effectively doing a self-denial-of-service because of the way one resource hungry plugin was configured, and running multiple instances, in parallel across multiple domains.

Great news awaits … this excessive peek-demand can be avoided while still providing the desired business outcome for content link quality.

Passive Business Policy for Link Quality

Lets go back a step and choose a passive business policy to dealing with broken links.

The desired outcome is to keep the monthly server financial expense as-is and spread out the resource demands over time; effectively chopping the top off that peek-demand.

A passive use of the broken link checker (local) plugin ensures the minimum hardware requirements for the website owners monthly hosting expenses, remains low.

It starts with the website owner managing their expectations.

Instead of doing an aggressive full website content link check every 8 hours; officially do it once every 3 months, knowing content edits are done within a few hours and that the quarterly check might take a few hours or days. Yes, days, which you still do not really care about because it is an automated quarterly full check that will send you an email when completed.

A passive business policy saves man-hours, brings peace of mind and no demand to increase the monthly hardware expenses. Making it worth you time to challenging your business policy; vote for passive resource usage and configure the broken link checker (local) plugin to process the ‘link queue’ in tiny steps.

How-To Configure Broken Link Checker

• Log in to the website administration area, as a WordPress admin.
• Visit ‘Link Checker’ -> ‘Local [Old]’ menu.
• Select ‘General’ tab.
  • Enter 2184 in the ‘Check Each Link’ option (~3 months worth of hours).
  • Tick the ‘Send me email notifications about newly detected broken links’ option.
  • Enter your email address in the ‘Notification Email Address’ option.
  • [Optional] Tick the ‘Stop search engines from following broken links’ option.
  • [Optional] Tick the ‘Show uncertain or minor problems as warnings instead of broken’ option.
  • [Optional] Tick the ‘Disable post modified date change when link is edited’ option.
  • Click [Save] button.

• Select ‘Advanced’ tab.
  • Enter 33 in the ‘Timeout’ option.
    • Hint: Do you really want to link to slow websites?
  • Untick the ‘Run continuously while the Dashboard is open’ option.
  • Untick the ‘Run hourly in the background’ option.
  • Enter 55 in the ‘Max. Execution Time’ option.
  • Enter 3 in the ‘Server Load Limit’ option.
  • Slide to 1% for the ‘Target Resource Usage’ option.
  • Untick the ‘Logging’ option.
  • Click [Save] button.

• Ensure the website has a server scheduled cron trigger.
  • Hint: This will help all of the background jobs to spread out over time and not be bunched up into a less-regular schedule, like only once a day (undesirable in a lot of use cases).
  • Hint: Do not relying on website traffic to trigger background cron actions.

This screenshot shows that the broken link checker (local) plugin has been actively processing new content links, over the last few hours as new website content is added. From 87 to 94 unique links, processed in the link queue.

Broken Link Checker Success and 2 Warnings

Over the last 5 hours, since 11:00am, lots of WordPress housekeeping has occured across 9 unique domains, aka WordPress installations, and the ‘Idle CPU’ resource usage graph for a single-host single-cpu-core system is telling a much happier and healthy story; yes, even a few manual full content link checks covering thousands of content links were triggered and completed.

[Warning] Stay away from the ‘Run continuously while the Dashboard is open’ option. From 05:30 – 08:30 am the ‘run continuously in dashboard’ option significantly interferred with getting other activities done. Including several self-denial-of-service moments because the CPU was red-lining and then the web server was not really able to take requests. Ouch.

[Success] A passive business policy in action for a CPU resource hungry plugin.
After 08:30 am, with unticked ‘run continuously’ and unticked ‘run hourly’ options.

[Warning] Stay away from the ‘Run hourly in the background’ option. After turning it on, the server side PHP-FPM pool jobs continually over-spawned to keep the CPU at +99% for litterally hours; despite the broken link checker (local) plugin reporting that all ‘link queues’ were fully processed across all the unique domains hosted on the server. Only a server reboot was able to make them go away, and not come back.

Success a Week Later

Running 12 low-traffic WordPress websites and another ~20 static websites on a single-host single-cpu-core system with frequent server-side cron triggers … and the ‘Idle CPU’ resource usage graph is telling a happy-n-healthy story; now that Broken Link Checker is playing nice along-side the other configuration optimisations.

• Leveraging Amazon S3 Buckets and CloudFront for hot-link protected media.
• Leveraging Object Cache Pro for in-memory database read optimisation.
• Leveraging WP Rocket for page caching; public and logged in user unique content.
• Leveraging Autoptimize for only the CSS & JS minification and bundeling.
• Leveraging Unbloater for all its great WordPress optimisations and housekeeping.
• Running aggresive server-side cron to minimise background action in user requests.
• No Varnish, no Breeze, no Memcahced … as the above tools proved to be faster.
• Yes, the spikes down to ~70% CPU are aligned with manual administration actvitities in disabled-optimisation sessions with many cache rebuilds.