Improve OPcache performance guidance - #403
Conversation
mindctrl
left a comment
mindctrl
left a comment
There was a problem hiding this comment.
LGTM. Left a question about opcache config.
|
Solid expansion of the Opcode Cache section. The added detail on opcache.validate_timestamps and revalidate_freq, deployment invalidation, monitoring for memory and max_accelerated_files limits, and the tradeoffs between development and production is genuinely useful and actionable. I verified the two internal cross links resolve: performance.md#opcode-cache and security.md#opcache-security both match existing headings, so the shared hosting security pointer lands correctly. It reads well and stays consistent with the Server Environment entry. LGTM. |
kittenkamala
left a comment
kittenkamala
left a comment
There was a problem hiding this comment.
Great work! Thank you so much. I made a few suggestions here for adjusting language. Otherwise I think this is good to go.
github-project-automation
Bot
moved this from Todo
to Changes Requested
in WordPress Hosting Team
Adopts kittenkamala's review suggestions: expand OPcache intro with extension/version detail, soften production recommendation phrasing, and clarify interned strings description.
79129bb to
1a302a7
Compare
|
Thanks @kittenkamala! Applied all three wording suggestions in 1a302a7 - ready for another look. |
kittenkamala
added
WCUS26
4 participants
What this changes
Expands the existing Opcode Cache guidance in the Performance page with practical OPcache notes for WordPress hosting environments.
This also updates the
opcacheentry on the Server Environment page so it describes bytecode caching and links back to the performance guidance.Why
OPcache is already mentioned in the handbook, but the current guidance is brief. This adds more actionable information about production use, timestamp validation, deployment invalidation, monitoring, and shared-hosting security considerations.
Related issue
Fixes #293