Architectural Design of a Native PHP Grapheme-to-Phoneme Transduction Engine for Elder Futhark Transliteration

Full report

On this page

Introduction and Linguistic Framework

The transliteration of modern English orthography into the ancient Elder Futhark runic script presents a profound intersection of historical linguistics, phonology, and computational software architecture. The Elder Futhark is universally recognized as the oldest fully formed runic alphabet, utilized by Germanic peoples primarily during the Migration Period to record Proto-Germanic and Proto-Norse dialects1. The script consists of twenty-four runes, traditionally divided into three groups of eight known as ættir, which reflect deliberate phonological organizations by ancient runemasters1. Because the script was fundamentally phonetic—designed to accurately represent the spoken phonological inventory of late Proto-Germanic—it lacks the capacity to directly encode modern English spelling1.

Modern English orthography is deeply opaque, characterized by a massive divergence between written graphemes and spoken phonemes. This historical decoupling is primarily the result of the Great Vowel Shift, alongside centuries of loanwords and the retention of obsolete spellings without subsequent orthographic standardization1. Consequently, implementing a direct, one-to-one character substitution algorithm (e.g., mapping the Latin letter 'C' to a single rune regardless of whether it represents the /k/ sound in "cat" or the /s/ sound in "city") produces historically inaccurate and unpronounceable gibberish1. To achieve an authentic programmatic conversion, the input text must be structurally bypassed and translated based strictly on its acoustic reality.

Modern computational systems typically facilitate this translation through Grapheme-to-Phoneme (G2P) transduction, converting English text into intermediate phonetic representations before mapping those distinct sounds to their closest Elder Futhark equivalents1. While contemporary NLP architectures frequently rely on Python-based neural networks (such as Sequence-to-Sequence models) or third-party deep learning toolkits, strict architectural constraints often necessitate a completely native solution1. Developing this system entirely within native PHP 8.x—without relying on external libraries, API calls, or compiled C-extensions beyond the core Zend Engine—requires a highly optimized, multi-stage pipeline. The proposed architecture must exploit native PHP associative arrays, advanced Perl-Compatible Regular Expressions (PCRE), generator-based memory management, and shared-memory opcode caching to achieve efficient, real-time transduction1.

The overarching software architecture is divided into deterministic data transformations. The pipeline ingests raw string data, normalizes it into discrete, phonetically viable tokens, transduces those tokens into ARPABET phonetic codes using a hybrid dictionary and rule-based fallback engine, sanitizes the resulting phonemes, and ultimately routes them through a multidimensional runic mapping matrix1.

Phase 1: Text Normalization and Tokenization Engine

Before phonological evaluation can occur, the raw English input string must be strictly sanitized and tokenized. Ancient runic epigraphy did not utilize modern syntactical markers, Arabic numerals, or Latin abbreviations. Therefore, the normalization engine acts as a strict gatekeeper, guaranteeing that only pronounceable alphabetic data reaches the G2P parser1.

Alphabetic Sanitization and Unicode Compliance

The initial processing layer relies heavily on PHP's preg\_replace function to execute pattern matching and substitution. To ensure total compatibility with multi-byte characters and to prevent string encoding malformations when injecting Unicode runic characters later in the pipeline, all regex operations must strictly append the u (PCRE\_UTF8) modifier5. The absence of the u modifier in PHP regex functions handling non-ASCII multibyte text results in byte-level truncation, generating malformed substitution artifacts8.

The string processing executes sequentially, beginning with a complete lowercasing operation via mb\_strtolower to normalize the data for case-sensitive dictionary lookups1. Following this, punctuation and specialized characters are either unconditionally purged or conditionally preserved for syntactical mapping. Modern syntactical markers, such as commas and semicolons, are typically targeted by a regex pattern designed to strip anything outside of the Unicode property classes for letters, numbers, and whitespace2. Upon the successful removal of non-alphabetic artifacts, the string undergoes tokenization. The normalized text is split into an array of discrete word tokens using the explode function on whitespace delimiters, ensuring that contiguous spaces are algorithmically collapsed prior to tokenization to prevent the generation of empty, unprocessable array elements1.

Programmatic Numeral-to-Text Conversion

A critical challenge in runic transliteration is the presence of numeric data. Because the Elder Futhark does not contain characters for Arabic numerals, numbers cannot be transliterated; they must be phonetically vocalized. A string containing "1996" must be algorithmically expanded into its spoken English equivalent (e.g., "one thousand nine hundred ninety-six") before phonetic parsing can occur1. The PHP architecture implements a recursive digit-parsing algorithm capable of handling arbitrarily large integers, relying entirely on native math functions and localized arrays.

The algorithm establishes a set of static arrays containing the English string equivalents for units ("one", "two"), teens ("eleven", "twelve"), tens ("twenty", "thirty"), and exponential scales ("thousand", "million", "billion")10. The core logic evaluates the numeric input by segregating it into modulo-1000 chunks, processing the number from right to left in three-digit segments10. Within any given three-digit segment, the hundreds place is isolated by dividing the chunk by one hundred and flooring the result10. The tens and units are similarly isolated using modulo 100 and modulo 10 arithmetic10.

To handle massive numeric values, the function leverages recursion. If a number exceeds a defined scale threshold, such as one million, the algorithm recursively calls itself, passing the floored quotient of the number divided by the scale factor, appends the appropriate scale string from the array, and then continues processing the remainder via modulo division10. This completely native PHP implementation fully replaces the need for external formatting libraries, ensuring that all numeric data is smoothly expanded into phonetic English tokens before entering the transduction engine.

Phase 2: Native Grapheme-to-Phoneme Transduction

Once the input is tokenized into a normalized array of alphabetic strings, the system must bridge the orthographic gap using the ARPABET phonetic code. ARPABET is a standard computational linguistics mapping system developed by the Advanced Research Projects Agency, which translates the phonemes and allophones of General American English exclusively into machine-readable ASCII characters1. In the absence of machine learning sequence-to-sequence models or external Python libraries, the PHP architecture relies on a hybrid G2P engine: a massive static dictionary array for known vocabulary, supported by a deterministic, rule-based fallback algorithm for Out-Of-Vocabulary (OOV) words.

The Primary Lexicon: Zend Engine HashTable Optimization

The primary translation mechanism is a localized, multidimensional associative PHP array that functions as the Carnegie Mellon University (CMU) Pronouncing Dictionary1. This static dictionary maps correctly spelled English words (acting as the array keys) to their exact ARPABET phonetic representations (acting as the values).

The fundamental architectural decision in this phase involves the underlying data structure. While prefix trees (Tries) are highly efficient data structures in memory-constrained environments like C++, implementing a Trie purely in PHP userland introduces massive execution overhead14. Object-oriented Node classes in PHP carry significant memory penalties per instantiation, resulting in execution times that can be exponentially slower than native array handling15. Consequently, the optimal architecture leverages PHP's native associative arrays, which the underlying Zend Engine manages as highly optimized HashTables14. Lookups performed via the isset() language construct execute in theoretical O(1) time complexity, drastically outperforming linear array searches like in\_array() or manual graph traversal17.

Loading an associative array containing over one hundred and thirty-four thousand key-value pairs inherently carries a memory footprint1. In legacy PHP 5.x architectures, HashTables required separate, double-linked allocations for buckets and zval (Zend value) structures, heavily inflating the per-element memory usage to approximately 104 bytes plus 96 bytes per element16. However, the modern PHP 8.x Zend Engine utilizes a packed array structure where the zval is embedded directly into the bucket structure, eliminating double refcounting, discarding the need for separate allocation headers, and reducing memory usage by well over sixty percent16. Because modern complex values embed a internal reference count, identical strings can be shared across the system independently of the zval mechanism16.

This underlying C-level optimization means the entire CMU dictionary can be efficiently stored as a static array returned directly from an included .php file. To bypass disk I/O and parsing overhead on every execution, this dictionary file must be cached directly in shared memory using the PHP OPcache extension20. By configuring the server to load the array via OPcache, PHP serves the pre-compiled, native hash array directly from RAM with zero runtime deserialization penalty, significantly outperforming external, network-bound datastores for this specific intra-application, read-heavy workload20.

The Fallback Engine: The Naval Research Laboratory Algorithm

When the O(1) dictionary lookup fails to locate a token—a frequent occurrence with proper nouns, domain-specific neologisms, and dialectal slang—the system routes the unknown word to the rule-based fallback engine1. Without access to predictive neural modules, this engine implements a native PHP version of the historic Naval Research Laboratory (NRL) Text-to-Phoneme algorithm, originally developed in 1976 for early text-to-speech synthesizers22.

The NRL algorithm utilizes a prioritized, cascading array of context-aware grapheme-to-phoneme rules23. In the original SNOBOL4 specification, rules were defined using an explicit syntax dictating the preceding context, the exact character match, the subsequent context, and the resulting phoneme23. The modern PHP implementation translates this logic into a massive array of Perl-Compatible Regular Expressions, processing the unknown word through a cascading preg\_replace sequence that applies phonetic heuristics based on the surrounding graphemic environment5.

The rules are strictly ordered from the most specific context to the least specific fallback23. A critical responsibility of this engine is resolving the deep ambiguity of the English letters "C" and "G" based on historical phonological softening rules. The consonant C can represent the voiceless alveolar sibilant /s/ or the voiceless velar plosive /k/, while G can represent the voiced postalveolar affricate /dʒ/ or the voiced velar plosive /g/25. The NRL rules dictate that C and G typically mutate into their "soft" sounds when immediately followed by the front, softening vowels E, I, or Y25. Conversely, when followed by the "hard" vowels A, O, U, a consonant, or when appearing as the terminal character of a word, they retain their default velar plosive values25.

In the PHP regex implementation, this context awareness is achieved using positive lookaheads. The specific rule for a soft C translates to a regex pattern matching the literal 'c' only when followed by specific vowels, mapping to the phoneme S5. A subsequent default fallback rule lacking the lookahead catches all remaining instances of the letter 'c', mapping them to K5. By prioritizing the context-aware regular expression sequentially before the generic fallback expression in the array pipeline, the system accurately predicts pronunciation without requiring complex conditional nesting.

Furthermore, the fallback engine systematically collapses complex English orthography that violates runic phonetic structures. Digraphs—combinations of characters representing a single sound, such as "sh", "ch", "th", and "ng"—are caught by multi-character regex patterns and mapped directly to the singular ARPABET tokens SH, CH, TH, and NG1. This prevents the engine from erroneously evaluating the letters individually1. Double consonants, such as the double 'l' in the word "hello", are algorithmically collapsed into a single phonetic representation, respecting runic orthography which strictly avoids consonant doubling unless depicting genuine phonetic gemination1. Finally, recognized silent letters, such as the initial 'k' in "knight" or the terminal 'e' in "stone", are unconditionally omitted from the phonetic stream by mapping specific contextual patterns to a null string1. The ultimate output of the fallback engine is a string of ARPABET tokens matching the standardized format of the primary lexicon, allowing the pipeline to proceed uniformly regardless of the token's origin.

Phase 3: ARPABET Token Sanitization

Once the raw English text has been successfully converted into arrays of ARPABET phonetic codes, the data undergoes a final sanitization phase to prepare it for the runic transliterator matrix. The raw ARPABET output, particularly data sourced from the highly granular CMU dictionary, includes lexical stress markers appended directly to the vowels1.

The ARPABET standard utilizes integers to denote varying levels of vocal emphasis: a 0 indicates an unstressed vowel, a 1 indicates primary lexical stress, and a 2 indicates secondary stress (yielding tokens such as AH0, AY1, or UW2)1. Because the ancient runic script lacks any structural or diacritical mechanism for representing lexical stress, these numeric identifiers must be neutralized to prevent matrix lookup failures1. The PHP architecture executes an array\_map function across the phonetic tokens, utilizing a simplified preg\_replace operation to strip the trailing numeric characters, effectively reducing the tokens to their base alphabetic forms (e.g., reducing AY1 to AY)1.

The sanitization phase is also responsible for resolving syllabic consonants. Specific edge cases in the ARPABET system utilize distinct tokens for consonants acting as the vocalic nucleus of an unstressed syllable, such as EL representing the /l̩/ sound in "bottle" and EN representing the /n̩/ sound in "button"1. Because runic orthography did not differentiate syllabic consonants structurally from standard consonants, the sanitization script maps these tokens sequentially to their standard counterparts, reducing EL down to L and EN down to N1. This programmatic reduction relies on the eventual human reader to infer the vocalic weight based on context, thereby streamlining the inventory of tokens required for the final mapping matrix1.

Phase 4: The Transliterator Matrix (Phoneme-to-Rune)

The core logic and final execution of the programmatic transliteration relies on a multidimensional PHP matrix. This matrix maps the thirty-nine distinct, sanitized ARPABET phonemes down to the twenty-four Unicode characters of the Elder Futhark1. Because the Elder Futhark was expressly designed for the Proto-Germanic phonetic inventory, attempting to compress the expansive phonology of modern English into this ancient script necessitates deliberate algorithmic approximations1. The PHP engine iterates over the sanitized ARPABET array and performs rapid hash table lookups against this translation matrix.

Table 1 details the programmatic mapping logic for consonant phonemes, providing the targeted Elder Futhark rune, its Unicode hex value, and the phonological justification for the specific architectural reduction1.

 

The mapping of vowels presents the highest degree of programmatic difficulty. The vowel inventory of modern English is vastly more expansive than the basic five-to-six vowel system utilized in Proto-Germanic. Furthermore, modern English contains a wealth of expansive diphthongs entirely absent from the target script1. To resolve this, the transliteration matrix algorithmically maps single vowels to their closest articulatory and etymological equivalents, while strictly splitting diphthongs into sequential constituent vocalizations.

Table 2 outlines the mapping architecture for modern English vowels and complex diphthongs1.

 

Upon successful querying against this matrix, the resulting Unicode hex values are pushed into a buffered output array. Word boundaries, which were extracted during the initial whitespace tokenization phase, are algorithmically re-injected into the output buffer, mapped to the Unicode Runic Word Separator (᛫, U+16EB)1. If the user opts to retain standard punctuation during the normalization phase, those markers are translated to the multiple-dot sentence separator (᛬, U+16EC) to maintain epigraphic aesthetic continuity1. Finally, the array buffer is imploded into a cohesive, fully transliterated string ready for user presentation.

Memory Management and Execution Optimization

Constructing an exhaustive, multi-pass natural language processing pipeline native to PHP requires stringent control over server resources, particularly memory allocation limits and CPU execution thresholds. Processing large volumes of English text through a multi-pass regex engine, applying recursive numeric expansions, and executing thousands of queries against a 134,000-word lexicon can easily exhaust the Zend Engine's capacity, triggering Out-Of-Memory (OOM) fatal errors if the underlying software architecture is inefficient27. The final phase of this design encompasses the systemic optimizations required to operate at scale.

Generator-Based Lazy Evaluation

To prevent the application from loading entire monolithic texts or massive transitional array structures into memory simultaneously, the data flow between the four computational phases relies entirely on PHP Generators6. Generators provide a robust mechanism for creating iterators with minimal memory overhead, fundamentally altering how PHP consumes large datasets29.

Instead of normalizing the entire input text, storing the sanitized words in a massive array, and then passing that complete array to the G2P engine, the architecture utilizes a generator function featuring the yield keyword31. This allows the normalization phase to yield one sanitized word token at a time directly to the G2P transduction engine31. Consequently, the memory footprint remains constant regardless of whether the system is transliterating a single sentence or processing an entire novel29. The generator pauses its internal execution, yields the token to the transduction matrix, waits for the phonetic output, and then resumes operation for the subsequent token29. This lazy evaluation ensures that only the currently active data slice is held in volatile memory27.

Furthermore, to maintain a strict memory ceiling during the execution of the fallback engine, temporary variables and context buffers used during the complex regex evaluations are explicitly destroyed using unset() immediately upon token resolution27. This actively frees memory blocks rather than waiting for the script's natural termination28. In long-running CLI transliteration jobs, gc\_collect\_cycles() can be invoked strategically to force the Zend Engine's garbage collector to clear circular references that may accumulate during deep recursion in the numeral-to-text translation function28.

OPcache Tuning and Preloading Mechanisms

To extract the maximum performance from the static CMU dictionary array, the hosting server's PHP OPcache extension must be meticulously tuned32. OPcache dramatically improves PHP execution time by storing precompiled bytecode directly in shared memory, effectively bypassing the tokenization, parsing, and compilation overhead on every subsequent request32.

For this specific natural language architecture, the dictionary .php file must be heavily cached. Standard, conservative OPcache defaults are entirely insufficient for managing data structures of this magnitude, necessitating specific adjustments to the php.ini configuration:

• opcache.memory\_consumption: The default value of 128 megabytes should be increased to at least 256 or 512 to accommodate the large CMU associative array alongside standard application code without triggering continuous cache evictions33.
• opcache.interned\_strings\_buffer: This buffer is dedicated to storing immutable, deduplicated strings33. Given the massive amount of string keys and values present in the 134,000-word dictionary, the default value of 8 megabytes is insufficient. This should be increased to 16 or 32 megabytes to prevent premature cache saturation and performance degradation33.
• opcache.max\_accelerated\_files: The total number of scripts allowed in the cache must be increased to at least 20000 to ensure that both the extensive array files and the intricate fallback rule definitions are persistently held in memory33.
• opcache.preload: Introduced in PHP 7.4, the preloading feature represents a paradigm shift for applications reliant on large static datasets. By configuring opcache.preload to point to the dictionary initialization script, the transliteration engine and its lexicon are permanently compiled and loaded into the Zend Engine's memory upon server startup38. This completely negates cold-start latency, rendering the massive associative array globally available to all PHP FastCGI workers with zero individual compilation overhead39.

JIT Compilation for CPU-Bound Workloads

While standard web applications—such as database-backed content management systems—are typically I/O bound, this transliteration architecture is intensely CPU-bound due to its reliance on continuous preg\_replace sequence operations, complex string manipulation, and recursive parsing loops. Enabling the PHP 8 Just-In-Time (JIT) compiler provides measurable throughput gains for this exact operational profile40. By configuring opcache.jit=1255 and allocating a dedicated memory buffer via opcache.jit\_buffer\_size=256M, the server translates the Zend intermediate opcodes directly into native machine code at runtime40. This JIT translation significantly accelerates the execution speed of the intensive NRL fallback algorithms, reducing CPU cycles spent on pattern matching and accelerating the final throughput of the transliteration pipeline40.

Architectural Synthesis

Designing a native PHP program to execute historical linguistic transliteration without reliance on third-party NLP libraries demands a deep synthesis of computational linguistics and low-level engine optimization. Because the modern English language features a deeply opaque orthography that cannot be directly mapped to the phonetic structures of the Elder Futhark, the software architecture must act as a Grapheme-to-Phoneme translator before any runic mapping can occur.

By executing a phased approach—beginning with strict Unicode normalization and recursive numeric expansion, moving through an OPcache-accelerated native array for O(1) primary dictionary lookups, and relying on context-aware Perl-Compatible Regular Expressions for historical consonant softening and fallback heuristics—the system successfully abstracts the orthographic complexity of English. Subsequently mapping the sanitized ARPABET phonemes through a specialized, historically approximated matrix yields an accurate, programmatic transliteration. Through the strategic implementation of memory-efficient generators, packed arrays, and aggressive OPcache tuning, this architecture successfully delivers a highly performant, culturally accurate computational linguistics engine utilizing exclusively native PHP capabilities.

Works cited

1. Elder Futhark Phonetic Conversion.md

2.  

3. A Rule-Based Grapheme-to-Phoneme Conversion System \- MDPI, https://www.mdpi.com/2076-3417/12/5/2758

4. Grapheme-to-Phoneme Models \- NVIDIA Documentation, https://docs.nvidia.com/nemo-framework/user-guide/latest/nemotoolkit/tts/g2p.html

5. Replacing ereg\_replace() with preg\_replace() in PHP for Regex, https://medium.com/@wearedopethemes/replacing-ereg-replace-with-preg-replace-in-php-for-regex-handling-e4cdf53450e2

6. Generators overview \- Manual \- PHP, https://www.php.net/manual/en/language.generators.overview.php

7. Regular Expressions: The Complete Tutorial \- GitHub Pages, https://gotellilab.github.io/Bio381/Scripts/Feb07/RegularExpressionsTutorial.pdf

8. PHP and Unicode: Handling Multilingual Text and UTF-8 \- Reintech, https://reintech.io/blog/php-unicode-handling-multilingual-text-utf8

9. PHP how to convert number (year) to text ex. 1996 \= Ninteen Ninty, https://stackoverflow.com/questions/62463611/php-how-to-convert-number-year-to-text-ex-1996-ninteen-ninty-six-and-2004

10. How to Convert a Given Number to Words in PHP? \- GeeksforGeeks, https://www.geeksforgeeks.org/php/how-to-convert-a-given-number-to-words-in-php/

11. Convert Number to Words \- AlgoDaily, https://algodaily.com/challenges/convert-number-to-words

12. How to transform numbers to words in the Indian/South Asian, https://stackoverflow.com/questions/14766951/how-to-transform-numbers-to-words-in-the-indian-south-asian-numbering-system

13. Convert given time into words \- GeeksforGeeks, https://www.geeksforgeeks.org/dsa/convert-given-time-words/

14. To Trie or not to Trie – a comparison of efficient data structures, https://news.ycombinator.com/item?id=1656104

15. Php prefix tree implementation versus assoc array \- Stack Overflow, https://stackoverflow.com/questions/36938662/php-prefix-tree-implementation-versus-assoc-array

16. PHP's new hashtable implementation \- nikic's Blog, https://www.npopov.com/2014/12/22/PHPs-new-hashtable-implementation.html

17. List of Big-O for PHP functions \- Stack Overflow, https://stackoverflow.com/questions/2473989/list-of-big-o-for-php-functions

18. Why objects (usually) use less memory than arrays in PHP, https://gist.github.com/nikic/5015323

19. internals:engine:objects \- PHP, https://wiki.php.net/internals/engine/objects

20. The PHP Performance Trick Nobody Talks About \- Medium, https://medium.com/@pratikmachchar/the-php-performance-trick-nobody-talks-about-switching-to-opcache-1de7edb05483

21. php's OPcache can get saturated \- Plum Island Media, https://www.plumislandmedia.net/programming/php/phps-opcache-can-get-saturated/

22. GitHub \- Lord-Nightmare/NRL\_TextToPhonemes, https://github.com/Lord-Nightmare/NRL\_TextToPhonemes

23. greg-kennedy/p5-NRL-TextToPhoneme \- GitHub, https://github.com/greg-kennedy/p5-NRL-TextToPhoneme

24. TEXT-TO-SPEECH RULE AND DICTIONARY DEVELOPMENT, https://assta.org/proceedings/sst/SST-86/cache/SST-86-Chapter1-p14.pdf

25. Soft C and Soft G Rules: When C Says /s/ and G Says /dʒ/ in English, https://www.learnenglishsounds.com/en/blog/soft-c-soft-g-pronunciation-rules-english

26. Teaching Hard and Soft G & C Sound Words with Gentle Cindy, https://mrslearningbee.com/learn/blog/teaching-hard-and-soft-g-sound-words-with-gentle-cindy

27. Efficient Memory Management for Large Arrays PHP 8.3 \- Synpass, https://synpass.pro/case-studies/efficient-memory-management-for-large-arrays-php-8-3/

28. PHP Memory Optimization Tips \- Medium, https://medium.com/@khouloud.haddad/php-memory-optimization-tips-f362144b9ce4

29. PHP Generators | Memory-Efficient Iteration \- Web Reference, https://webreference.com/php/advanced/generators/

30. PHP and Generators: Simplifying Iteration with Yield \- Reintech, https://reintech.io/blog/php-generators-simplifying-iteration-yield

31. Efficient Data Processing with PHP Generators \- DEV Community, https://dev.to/eddiegoldman/efficient-data-processing-with-php-generators-3kjc

32. PHP OPcache Quick Reference | Blog | Sydney Software Development, https://www.sydney.software/blog/php-opcache-quick-reference/

33. Boosting PHP performance: mastering OPcache optimization with, https://blog.blackfire.io/boosting-php-performance-mastering-opcache-optimization-with-blackfire.html

34. PHP OPcache Deep Dive: How to Tune It for Maximum Performance, https://phpbenchlab.com/php-opcache-deep-dive-tuning-benchmark-2026/

35. PHP and Performance Optimization: Tips and Techniques for Fast, https://reintech.io/blog/php-performance-optimization-tips-techniques

36. How to use PHP OPCache ? \- GeeksforGeeks, https://www.geeksforgeeks.org/php/how-to-use-php-opcache/

37. \[Bug\]: OPcache buffer & interned strings buffers always full \#44353, https://github.com/nextcloud/server/issues/44353

38. File php8.changes of Package php8 \- openSUSE Build Service, https://build.opensuse.org/projects/openSUSE:Factory/packages/php8/files/php8.changes?expand=0

39. How to enable optimizations in opcache (in an official php-fpm, https://stackoverflow.com/questions/57245658/how-to-enable-optimizations-in-opcache-in-an-official-php-fpm-docker-image

40. OPcache, PHP-FPM, Caching & Profiling \- EaseCloud, https://blog.easecloud.io/cloud-infrastructure/master-php-performance-optimization/

41. php opcache explained \- luroConnect, https://www.luroconnect.com/blog/php-opcache-explained