Read WordPress Runtime Signals Before Changing Limits

Limits are not capacity

A request cap answers a narrow question

PHP’s memory_limit limits memory a script may allocate during a request. WordPress memory constants request values from PHP; they do not report the resident memory of a PHP process or the free memory of the server. A setting visible in a panel is configuration evidence, not a measurement of what a real request consumed. It also does not say whether a particular page, import, image task, or plugin can finish within that limit.

Do not multiply the request limit by a site count or worker setting and label the result “RAM required.” Such arithmetic treats a ceiling as observed use, assumes identical simultaneous processes, and leaves out shared and non-PHP services. Those assumptions are not measurements.

Workers create concurrency, while the host is shared

The PHP-FPM configuration manual defines pm.max_children as the number of child processes to create in static mode, and the maximum child-process count in dynamic or ondemand mode; it also states that the directive limits simultaneous requests served. In static mode the configured child count is fixed. Dynamic mode varies the process count using its related directives, while ondemand spawns processes when requested and limits their count by pm.max_children. This describes the directive’s scope, not safe host capacity, resident memory, or a per-site formula. It does not identify this server’s installed pool mode or configured value, and no representative workload or host measurement was made.

The operating system, web server, database, panel, filesystem cache, opcode and object-cache services, scheduled jobs, and any co-resident applications may draw on the same physical resources. Pools are not complete security isolation. Ask the runtime operator which pool and host metrics are available, and whether they cover all relevant services. The hub’s workload map helps name routes and jobs before this observation; co-resident workflow questions belong with the same-box boundary page.

Write down the observation, not a guess

For each observation, record its timestamp and window, route or job, active and idle worker counts if available, process peak and its source, host memory and swap observations, CPU and I/O signals, database activity, co-resident work, coincident events, observer, and confidence. Include units and the tool or report that produced a value. Leave a field blank when the source does not expose it; do not fill gaps with a typical value. A quiet snapshot cannot represent a different time window unless the owner establishes that it does.

Evidence boundary: WordPress’s PHP guidance describes the request limit and WP memory constants; PHP-FPM documents pool process controls. The local evidence set includes C007 and C004, with C004 only a search-result excerpt. These sources explain terms, not this server’s state.

Distinguish cache layers

OPcache stores compiled PHP bytecode

OPcache stores precompiled PHP bytecode to avoid loading and parsing scripts for every request. PHP documents shared-memory behavior for OPcache. This is different from retaining WordPress objects or serving a cached page. Ask who configures the extension, which processes share it, where its status is visible, and what event or procedure invalidates it. The answer depends on the installed PHP build and configuration; a plugin label does not establish the active OPcache setup.

Object cache and page cache answer different questions

The WordPress object-cache API gives code a way to retrieve stored objects. Persistence across requests normally requires an installed persistent-cache implementation and its working backend; WP_CACHE alone does not prove that objects persist. Redis or Memcached arrangements require the relevant service and PHP extension as well as compatible plugin or drop-in configuration. Record the actual owner and evidence for each component rather than inferring it from an admin screen.

A page cache or CDN may serve a rendered response without running the same application path on every visit. Its invalidation and bypass rules differ from object-cache invalidation. A cache hit in one layer does not prove that database work fell for every route, that writes remain consistent, or that the application can scale horizontally. Ask what is cached, for whom, for how long under the selected configuration, and what change makes it stale.

Database workset is another layer

Database buffers and the active data/query workset belong to the database process. They are not the WordPress object cache. They may share host memory with PHP and other services. No buffer size or cache ratio can be recommended from the accepted evidence here; obtain database-owner observations and workload-specific review.

Name what is stored and who invalidates it

Use one row per layer. Record item or response stored; persistence across requests; service, extension, plugin or CDN owner; invalidation trigger and authority; expected failure behavior; multisite namespace separation; and the source of any hit/miss statistic. If the source is absent, mark it unknown. A green plugin status or a configured constant is not evidence that the intended backend is reachable or that invalidation behaves correctly.

Evidence boundary: C005 identifies OPcache’s purpose; C008 and the WordPress object-cache reference describe persistence distinctions and backend dependencies. The excerpts do not establish any installation’s configuration or performance.

Database and worker work

Ask the database owner for workload evidence

Record the installed database version and who manages it, then request observations relevant to the site’s work: connection activity, query or job source, data size and change over the stated period, temporary-table or buffer behavior if the operator exposes it, disk and log growth, and space needed for the operator’s backup or repair process. Include the source, collection window, units, and known omissions. These are questions for the responsible operator, not a checklist that implies every system exposes the same metrics.

Scheduled work changes the observation window

WordPress’s built-in WP-Cron checks for due jobs when visits occur. WordPress says replacing that trigger is optional; the site owner and operator must decide whether a different schedule is appropriate. An external scheduler changes who controls timing and failure handling. Before any future change, identify whether it could leave both triggers active, who owns retries, and how duplicate work is prevented. Do not disable one trigger or configure another as part of this worksheet.

Imports, publishing tasks, plugin jobs, and other scheduled work can add PHP and database activity at times a quiet page visit will not show. This is a reason to ask for a representative window, not a claim that a burst occurs on a specific site. Note which events overlap the observation and which are missing.

Record every co-resident task and its owner

Ask whether backups, imports, image processing, workflows, model tasks, or maintenance jobs share the host, filesystem, database, or schedule. For each, write the operator, concurrency window if known, resources or data it can touch, evidence source, and who can stop or reverse a later change. Do not assume an unused reserve, non-overlap, or isolation. If the job owner or its access is unknown, keep it as an open dependency.

Evidence boundary: C007 supports the WP-Cron trigger description; C009 addresses MySQL release lifecycle, not workload sizing. Coordinator captures PHPFPM, MYSQL80REL, and MYSQL84 are upstream documentation excerpts. No database or host activity was observed for this manuscript.

Observation and change worksheet

Use this register to plan a future review. It is an observational worksheet, not a procedure already carried out. The site owner selects a representative route or job and explains why it matters. The runtime or database operator identifies available instrumentation and its limits. A second operator reviews whether the evidence covers relevant workload and whether a reversal is authorized. If any role is unassigned, collect the missing ownership information and stop before proposing a setting change.

1. wp-runtime-rb01-baseline

   Record the site or environment, route and job, time window, reason it represents the decision, event schedule, observer, and instrumentation source. Do not run a load test or make a live change under this worksheet.

2. Correlate layers

   Place process, host, database, cache, and scheduled-work observations on the same timeline where sources permit. Mark gaps and mismatched windows. A quiet instant does not stand in for a job burst.

3. Check compatibility evidence

   Record PHP and database versions, WordPress and plugin versions in scope, the exact compatibility source, its date, and who checked it. A vendor’s general compatibility statement does not identify the site’s installed versions.

4. Describe and bound a proposal

   Name the configuration and its owner; capture the current value and source; state the proposed value only if supplied by an accountable operator; explain the expected effect and what observable signal would confirm or contradict it. This article supplies no candidate value.

   Before any separately approved change, identify the authorized window, prior value and source, person with permission to restore it, validation owner, stop condition, and how the operator will know to stop. If the prior state or reversal authority is unknown, do not proceed.

5. Independent review

   A second operator checks that the workload window is representative, version evidence applies, missing signals are visible, and rollback is feasible. If the review cannot establish those points, the result is “insufficient evidence,” followed by a request for better observations.

For shared workflow timing, return observations through the co-residency worksheet; that page should hand runtime observations back here. For multisite or staging governance, see the environment decision. This page owns PHP, database, and cache interpretation; those pages own their respective architecture questions.

Verification and stop bounds: The record is reviewable when every populated value has a source, date/window, unit, observer, and owner; blank values remain visibly unknown. Stop at evidence collection if instrumentation is unavailable, windows do not overlap, compatibility is unverified, or no authorized person can restore the prior setting. No live host was inspected and no change, benchmark, or rollback was performed.

Lifecycle is not availability

PHP branch dates describe upstream support

The PHP supported-versions table captured on 2026-11-06 lists these branch dates: PHP 8.2 active support ended 2024-12-31 and security support ends 2026-12-31; PHP 8.3 active support ended 2025-12-31 and security support ends 2027-12-31; PHP 8.4 active support ends 2026-12-31 and security support ends 2028-12-31; PHP 8.5 active support ends 2027-12-31 and security support ends 2029-12-31. These are upstream branch lifecycle dates, not evidence that a host offers a branch, that an installed site runs it, or that a plugin is compatible.

The accepted direct PHP supported-version capture is the relevant source for the complete table. Older core capture C006 was a search result with lower provenance and should not be used alone. Recheck the PHP owner page before publication or a runtime decision because schedules can change.

MySQL tracks have different scopes

Oracle’s MySQL 8.0 release notes state that MySQL 8.0 reaches end of life with version 8.0.46, in April 2026. The 8.0 release notes end at that release. The MySQL 8.4 manual describes LTS and Innovation as distinct upstream release tracks: LTS is intended for environments seeking a stable feature set and longer support period, while Innovation targets newer features and faster upgrade cycles. The manual describes Innovation support through the next Innovation release. These track descriptions do not establish what a host supplies or whether an application is compatible.

Before treating a version as an available candidate, have the responsible operator confirm the installed database and the service owner’s supported options. Have the application owner check WordPress and plugin compatibility against current primary material. This page does not recommend an upgrade path or claim that any particular site is ready to move.

Recheck volatile dates and site compatibility

Keep the date checked, source URL, source owner, and exact version in the register. Recheck upstream lifecycle pages near publication and before a change. Separately verify the site’s installed PHP and database versions and compatibility evidence for its actual WordPress, theme, and plugins. A lifecycle date cannot answer the compatibility question; a compatibility page cannot prove host availability.

No capacity claim

Return evidence and gaps, not a site count

Return the observation window and workload, source and observer, missing peak coverage, service owner, compatibility evidence and date, candidate question, validator, and reversal authority. The record may conclude that evidence is incomplete. A request limit, cache label, or quiet sample cannot support a site count, visitor estimate, RAM-per-site figure, database buffer recommendation, or benchmark; none is established by the accepted research.

Return evidence to the owning decisions

For ownership, return to the hub’s evidence map. For shared automation, use the co-residency review; for offer terms and cash costs, use the cost worksheet. This page contributes observations, not price or capacity claims. For multisite or staging boundaries, see the environment decision.

Date and compatibility review

Keep unknown fields open

No installed PHP version, FPM pool configuration, representative worker peak, host memory profile, database version, buffer or temporary-work behavior, object-cache backend, or multisite cache namespace was inspected for this manuscript. Do not assume any of them. The owner may obtain evidence from the appropriate operator or record “not stated” and defer a decision. These states differ from “not applicable,” which requires an owner’s reason.

Attach a source and recheck date to each volatile fact

Use a direct primary owner page for lifecycle claims, identify the page and date checked, and consult the accepted capture locator listed below. The captures are rendered excerpts, not original HTTP response bytes; their timestamps are dates without exact retrieval times. Recheck PHP and MySQL lifecycle material and the installed application’s compatibility evidence before publication. No runtime test, scan, update, database inspection, or host change was performed for this page.

Stop condition: If the installed versions or responsible operators cannot be identified, keep the compatibility decision open. If a proposed change lacks a named verifier, observable success/failure signal, or authorized reversal owner, do not advance it as an operational recommendation. Route unresolved ownership questions to the hub’s authority map.

Sources and updates

Sources below are primary documentation from the technical owner. Local evidence locators are included for traceability; the capture bundle records rendered excerpts and provenance limits. Access date for this manuscript: 2026-11-06. Recheck volatile lifecycle and compatibility pages before publication or a later operational decision.

• PHP project, Core php.ini directives (request memory limit); PHP-FPM configuration (pool modes and pm.max_children); and Supported Versions (direct current branch table). The distinct Stage 4 supplement STAGE4-PHP-FPM-CONFIG-SUPPLEMENT captured the official manual on 2026-11-06 at 17:51 EST: PHP-FPM-CONFIG.txt lines 160–175, with corresponding raw HTML directives pm and pm.max-children. Raw SHA-256 299eae4fd47f066587374ce4704da79d6bd040fb73372d68a815dd57ef147a1c; derived section-text SHA-256 49d0508b965809bb1416e3ba4b124745f6879fcf5783df1eb41dc02a11dd2778. This is supplemental Stage 4 evidence, not a change to accepted Stage 1. Core C004 remains a search-result excerpt only and supports its stated pool-isolation limitation, not the directive definition; C006 is also a search-result excerpt. Other local captures: coordinator PHPFPM, PHP-SUPPORTED; core C007.
• PHP project, OPcache manual. Local captures: C005 and coordinator PHPOPCACHE.
• WordPress.org Developer Resources, PHP performance, WP_Object_Cache reference, and Cron. Local captures: C007, C008.
• Oracle, MySQL 8.0 Release Notes (8.0.46 and EOL); MySQL Releases: Innovation and LTS. Local captures: C009 and coordinator MYSQL80REL, MYSQL84.

Sources explain upstream behavior and release policy. They do not establish host availability, a provider commitment, application compatibility, current installation, operational performance, or a tested outcome.