PHP 8.4.2 Released!

実行時設定

php.ini の設定により動作が変化します。

OPcache 設定オプション
名前 デフォルト 変更可能 変更履歴
opcache.enable 1 INI_ALL  
opcache.enable_cli 0 INI_SYSTEM PHP 7.1.2 と 7.1.6 の間では、デフォルトは 1 でした
opcache.memory_consumption 128 INI_SYSTEM  
opcache.interned_strings_buffer 8 INI_SYSTEM  
opcache.max_accelerated_files 10000 INI_SYSTEM  
opcache.max_wasted_percentage 5 INI_SYSTEM  
opcache.use_cwd 1 INI_SYSTEM  
opcache.validate_timestamps 1 INI_ALL  
opcache.revalidate_freq 2 INI_ALL  
opcache.revalidate_path 0 INI_ALL  
opcache.save_comments 1 INI_SYSTEM  
opcache.fast_shutdown 0 INI_SYSTEM PHP 7.2.0 で削除されました
opcache.enable_file_override 0 INI_SYSTEM  
opcache.optimization_level 0x7FFEBFFF INI_SYSTEM PHP 7.3.0 で 0x7FFFBFFF から変更されました。
opcache.inherited_hack 1 INI_SYSTEM PHP 7.3.0 で削除されました
opcache.dups_fix 0 INI_ALL  
opcache.blacklist_filename "" INI_SYSTEM  
opcache.max_file_size 0 INI_SYSTEM  
opcache.consistency_checks 0 INI_ALL PHP 8.1.18 と PHP 8.2.5 で無効。PHP 8.3.0 で削除。
opcache.force_restart_timeout 180 INI_SYSTEM  
opcache.error_log "" INI_SYSTEM  
opcache.log_verbosity_level 1 INI_SYSTEM  
opcache.record_warnings 0 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.preferred_memory_model "" INI_SYSTEM  
opcache.protect_memory 0 INI_SYSTEM  
opcache.mmap_base null INI_SYSTEM Windows のみ
opcache.restrict_api "" INI_SYSTEM  
opcache.file_update_protection 2 INI_ALL  
opcache.huge_code_pages 0 INI_SYSTEM  
opcache.lockfile_path "/tmp" INI_SYSTEM  
opcache.opt_debug_level 0 INI_SYSTEM PHP 7.1.0 以降で利用可能
opcache.file_cache null INI_SYSTEM  
opcache.file_cache_only 0 INI_SYSTEM  
opcache.file_cache_consistency_checks 1 INI_SYSTEM  
opcache.file_cache_fallback 1 INI_SYSTEM Windows のみ
opcache.validate_permission 0 INI_SYSTEM PHP 7.0.14 以降で利用可能
opcache.validate_root 0 INI_SYSTEM PHP 7.0.14 以降で利用可能
opcache.preload "" INI_SYSTEM PHP 7.4.0 以降で利用可能
opcache.preload_user "" INI_SYSTEM PHP 7.4.0 以降で利用可能
opcache.cache_id "" INI_SYSTEM Windows のみ。PHP 7.4.0 以降で利用可能
opcache.jit "tracing" INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_buffer_size 0 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_debug 0 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_bisect_limit 0 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_prof_threshold 0.005 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_max_root_traces 1024 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_max_side_traces 128 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_max_exit_counters 8192 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_hot_loop 64 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_hot_func 127 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_hot_return 8 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_hot_side_exit 8 INI_SYSTEM PHP 8.0.0 以降で利用可能
opcache.jit_blacklist_root_trace 16 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_blacklist_side_trace 8 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_max_loop_unrolls 8 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_max_recursive_calls 2 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_max_recursive_returns 2 INI_ALL PHP 8.0.0 以降で利用可能
opcache.jit_max_polymorphic_calls 2 INI_ALL PHP 8.0.0 以降で利用可能
INI_* モードの詳細および定義については どこで設定を行うのか を参照してください。

以下に設定ディレクティブに関する 簡単な説明を示します。

opcache.enable bool

オペコード・キャッシュを有効にします。 無効にした場合、コードは最適化もキャッシュもされません。 opcache.enable の設定を、実行時に ini_set() で有効化することはできません。 実行時にできるのは、無効化だけです。スクリプト内で有効化しようとすると、警告が発生します。

opcache.enable_cli bool

PHP の CLI 版に対してオペコード・キャッシュを有効にします。

opcache.memory_consumption int

OPcache によって使用される共有メモリ・ストレージのサイズ。( MB 単位) 設定できる最小値は "8" です。これより小さい値を設定しても、最小値が強制されます。

opcache.interned_strings_buffer int

インターン化 (intern) された文字列を格納するために使用されるメモリ量。( MB 単位)

opcache.max_accelerated_files int

OPcache ハッシュテーブルのキー(すなわちスクリプト)の最大数。 使用される現時点の値は、 素数の集合 { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521, 1048793 } のうち、 設定値以上の最初の数値です。 最小値は 200 です。最大値は 1000000 です。 これらの範囲外の値が設定されても、範囲内の値に設定し直されます。

opcache.max_wasted_percentage int

メモリが不十分な場合に、再起動がスケジュールされるまでに許される、無駄なメモリの最大の割合。 最大値は "50" です。これ以上の値が設定されても、最大値が強制されます。

opcache.use_cwd bool

有効にすると、OPcache は現行の作業ディレクトリをスクリプト・キーに追加します。 その方法によって、同じ基底名を持つファイル同士で起こりうる衝突を回避します。 このディレクティブを無効にするとパフォーマンスが向上しますが、既存のアプリケーションを破壊するかもしれません。

opcache.validate_timestamps bool

有効にすると、OPcache は、スクリプトが更新されたかを opcache.revalidate_freq 秒ごとにチェックします。 このディレクティブが無効な場合、ファイルシステムへの変更を反映するには、 opcache_reset() または opcache_invalidate() 関数を介して、 または Web サーバーを再起動して手動で OPcache をリセットしなければいけません。

注意: opcache.file_update_protectionopcache.max_file_size の値に0でない値が設定されている場合、OPcache はファイルのタイムスタンプをまだコンパイル時にチェックする可能性があります。

opcache.revalidate_freq int

更新のためにスクリプトのタイムスタンプをチェックする頻度。(秒単位) 0 にすると、OPcache は、リクエストごとに更新をチェックします。

この設定ディレクティブは、 opcache.validate_timestamps が無効の場合、 無視されます。

opcache.revalidate_path bool

無効にすると、 同一の include_path を使用する、 キャッシュされた既存のファイルが再利用されます。 したがって、同じ名前を持つファイルが include_path の他の部分にあると、それは見つかりません。

opcache.save_comments bool

無効にすると、最適化したコードのサイズを減らすために OPcode キャッシュからすべてのドキュメンテーション・コメントが廃棄されます。 この設定ディレクティブを無効にすると、注釈のためにコメント・パースに依存するアプリケーションおよびフレームワークを破壊するかもしれません。 それには、Doctrine、Zend Framework 2 および PHPUnit が含まれます。

opcache.fast_shutdown bool

有効にすると、それぞれに割り当てられたブロックを解放しない、高速シャットダウン・シーケンスが使用されます。 しかし、リクエスト変数のすべてのセットをひとまとめに割当てを解除することは、Zend Engine のメモリ・マネージャに依存します。

このディレクティブは、PHP 7.2.0 で削除されました。 高速なシャットダウンシーケンスの類の設定は、PHP本体に統合され、可能であれば自動的に使用されます。

opcache.enable_file_override bool

有効にすると、file_exists()is_file() および is_readable() が呼ばれた際に、 ファイルが既にキャッシュ済みかどうかをオペコード・キャッシュからチェックします。 これは、PHP スクリプトの存在および読み込み可能かをチェックするアプリケーションのパフォーマンスを改善させるかもしれません。 しかし、opcache.validate_timestamps が無効な場合に、 陳腐化した結果を返す危険があります。

opcache.optimization_level int

どの最適化パスが実行されるかコントロールするビットマスク。 デフォルトでは、すべての安全な最適化を適用します。 デフォルト値の変更が役に立つのは、 大半が最適化エンジンをデバッグ/開発する時です(opcache.opt_debug_level も参照ください)。

opcache.inherited_hack bool

この設定ディレクティブの値は無視されます。

opcache.dups_fix bool

"Cannot redeclare class" (クラスを再宣言できません)というエラーを回避する目的でのみ、このハックを有効にするべきです。

opcache.blacklist_filename string

OPcache ブラックリスト・ファイルの場所。 ブラックリスト・ファイルは、高速化すべきではないファイルの名前を 1 行につき 1 つ含むテキストファイルです。 ワイルドカードが許されます。そして、プレフィックスも提示できます。 セミコロンで始まる行は、コメントとして無視されます。

簡単なブラックリスト・ファイルは、以下の通りかもしれません。

; 特定のファイルに一致します。
/var/www/broken.php
; x で始まるすべてのファイルに一致するプレフィックス
/var/www/x
; ワイルドカード一致です。
/var/www/*-broken.php
opcache.max_file_size int

キャッシュできるファイル・サイズの最大。(バイト単位) これが 0 の場合、すべてのファイルがキャッシュされます。

opcache.consistency_checks int

ゼロ以外の場合、OPcache は、リクエスト N 回毎にキャッシュのチェックサムを検証します。 N は、この設定ディレクティブの値です。 パフォーマンスを損なうので、これはデバッグ時のみ有効にすべきです。

注意:

PHP 8.1.18 と 8.2.5 で無効になり、PHP 8.3.0 で削除されました。

opcache.force_restart_timeout int

キャッシュがアクティブではない場合に、スケジュールされた再起動が始まるのを待つ時間の長さ。(秒単位) タイムアウトに達すると、OPcache は何か具合が悪いとみなして、リスタートできるようにするためにキャッシュのロックを所持する処理を殺します。

opcache.log_verbosity_level が 2 以上の場合、警告発生時にエラーログに記録されます。

このディレクティブは、Windows ではサポートされていません。

opcache.error_log string

エラーに対するエラーログ。 空の文字列は、stderr と同様に扱われ、 結果として標準エラー(ほとんどの場合、Web サーバーのエラーログです)に送られるログになります。

opcache.log_verbosity_level int

ログ冗長レベルです。 デフォルトでは、致命的エラー(レベル 0 )およびエラー(レベル 1 )だけが記録されます。 利用できる他のレベルは、警告(レベル 2 )、情報メッセージ(レベル 3 )およびデバッグ・メッセージ(レベル 4 )です。

opcache.record_warnings bool

有効にすると、OPcache はコンパイル時の警告を記録し、 次回の include 時にもその警告を再度発生させます。 これは、コードがキャッシュされていたとしても同じです。

opcache.preferred_memory_model string

OPcache が使用する優先のメモリ・モデル。 空のままにすると、OPcache は最も適切なモデルを選びます。 それは実質的にすべての場合に正しい振る舞いです。

可能な値には、mmapshmposix および win32 があります。

opcache.protect_memory bool

スクリプト実行中に予期しない書込みから共有メモリを保護する。 これは、内部のデバッギングだけに役立ちます。

opcache.mmap_base string

Windows 上で共有メモリ・セグメントに使用される基底。 すべての PHP 処理は、共有メモリを同じアドレス空間にマップしなければいけません。 このディレクティブを使用すると、"Unable to reattach to base address" (基底アドレスに再アタッチできません) というエラーを修復できます。

opcache.restrict_api string

OPcache API 関数の呼び出しを、指定した文字列から始まるパス上の PHP スクリプトからだけに制限します。 デフォルトは "" で、これは、何も制限しないことを意味します。

opcache.file_update_protection string

ここで指定された秒数の間は、キャッシュすることを防ぎます。 これにより、不完全に更新されたファイルがキャッシュされることを防止します。 全てのファイルの更新がアトミックに行われる場合、 この設定を "0" に設定することで、パフォーマンスを向上させられる可能性があります。なぜなら、こうすることでファイルがすぐにキャッシュされるからです。

opcache.huge_code_pages bool

PHPコード(textセグメント)を HUGE PAGE にコピーする機能を有効にしたり、無効にしたりできます。 これにより、パフォーマンスは向上するはずですが、適切なOSの設定が必要です。 Linux では PHP 7.0.0 以降、FreeBSD では PHP 7.4.0 以降が必要です。

opcache.lockfile_path string

共用ロックファイルを格納する絶対パス (*nix のみ)

opcache.opt_debug_level string

異なった段階の最適化をデバッグするために、オペコードのダンプを生成します。 0x10000 を指定すると、あらゆる最適化の前にコンパイラが提供するオペコードを出力します。 0x20000 を指定すると、最適化されたコードを出力します。

opcache.file_cache string

ファイルベースのセカンドレベル opcode キャッシュを有効にし、そのディレクトリを設定します。 これは共有メモリ上の opcode キャッシュがいっぱいの時やサーバー再起動時、 もしくは共有メモリ上の opcode キャッシュをリセットした場合のパフォーマンスを向上させます。 デフォルトは "" で、これはファイルベースのキャッシュを無効にします。

opcache.file_cache_only bool

共有メモリ内でのオペコード・キャッシュを有効あるいは無効にします。

注意:

PHP 8.1.0 より前のバージョンでは、 既に収集されているファイルキャッシュに対してこのディレクティブを無効にするには、 手動でファイルキャッシュをクリアする必要があります。

opcache.file_cache_consistency_checks bool

ファイルキャッシュから読み込んだスクリプトのチェックサムの検証を有効あるいは無効にします。

opcache.file_cache_fallback bool

共有メモリへの再アタッチに失敗するプロセスについて、 opcache.file_cache_only=1 であるものとみなします (Windows のみ)。 ファイルキャッシュを明示的に有効にする必要があります。

警告

この構成オプションを無効にすると、プロセスの開始が妨げられる可能性があります。 そのため推奨しません。

opcache.validate_permission bool

キャッシュされたファイルのアクセス権限を現在のユーザーに対して検証します。

opcache.validate_root bool

chroot された環境での名前の衝突を防止します。 これは、chroot 以外でのファイルへのアクセスを防止するために、 chroot されたすべての環境で有効にする必要があります。

opcache.preload string

サーバーが起動した際にコンパイルされ、実行されるPHPスクリプトを指定します。 ここで指定したファイルは include されたり、opcache_compile_file() 関数で指定されることで他のファイルも事前ロードするかもしれません。 それらのファイルに指定された全てのエンティティ(e.g 関数やクラス) は、サーバーがシャットダウンされるまで、外部からのリクエストに対して利用できるようになります。

注意:

コードの事前ロードは、Windows ではサポートされていません。

opcache.preload_user string

指定されたシステムユーザでコードを事前ロードするようにします。 これは、特権がないシステムユーザに切り替える前に、 root で起動するサーバーの場合に役立ちます。 root ユーザでコードを事前ロードすることは、 セキュリティ上の理由からデフォルトでは禁止されています。 但し、このディレクティブに明示的に root を指定した場合は許可されます。

opcache.cache_id string

Windows では、同じユーザーアカウントで同じ PHP SAPI を実行し、 かつ同じ cache ID を持つ全てのプロセスが同一の OPcache インスタンスを共有します。 cache ID の値は自由に選べます。

ヒント

IIS の場合、異なるアプリケーションプールは 環境変数 APP_POOL_IDopcache.cache_id の値として使うことで、 それぞれが異なる OPcache インスタンスを持つことが出来ます。

opcache.jit string|int

典型的な使い方として、このオプションには以下の4通りの文字列を指定できます。

  • disable: 完全に無効にする。実行時にも有効にできません。
  • off: 無効にしますが、実行時に有効にできます。
  • tracing/on: トレーシングJIT を使う。 デフォルトはこの値です。ほとんどのユーザに推奨される値です。
  • function: 関数単位でJITを使う。

高度な使い方として、このオプションには4桁の整数値 CRTO を指定できます。 それぞれの桁の意味は下記のとおりです。

C (特定のCPU向けの最適化フラグ)
  • 0: 特定のCPU向けの最適化を無効にする
  • 1: CPU がサポートしている場合に、AVX の使用を有効にする。
R (レジスタの割り付け)
  • 0: レジスタ割り付けを行わない
  • 1: ブロックについて、ローカルレジスタ割り付けを行う
  • 2: グローバルレジスタ割り付けを行う
T (JITを行うトリガ)
  • 0: スクリプトの読み込み時に全ての関数をコンパイルする
  • 1: 最初の実行時に関数をコンパイルする
  • 2: 最初のリクエスト時に関数の実行をプロファイリングし、 ホットな関数を後でコンパイルします。
  • 3: その場でプロファイリングを行い、ホットな関数をコンパイルします
  • 4: 現在は使われていません。
  • 5: トレーシングJITを使う。 その場でプロファイリングを行い、ホットコードの断片のトレースをコンパイルします。
O (最適化レベル)
  • 0: JIT を使わない
  • 1: 最小限しかJITを使わない (通常のVMハンドラを呼び出す)
  • 2: VMハンドラをインライン化する
  • 3: 型推論を使う
  • 4: コールグラフを使う
  • 5: スクリプト全体を最適化する
"tracing" モードは、CRTO = 1254 に対応しています。 "function" モードは、CRTO = 1205 に対応しています。

opcache.jit_buffer_size int

コンパイル済みのJITコードを保存する共有メモリの合計サイズ。 0 を指定すると、JIT が無効になります。

intを使用する際、 その値はバイト単位で測られます。 この FAQ に記載された 短縮表記を使用することも可能です。
opcache.jit_debug int

どの JIT のデバッグ出力を有効にするかを指定するビットマスク。 指定可能な値については、zend_jit.h を参照ください (ZEND_JIT_DEBUG から始まるマクロ定義を検索してください)。

opcache.jit_bisect_limit int

一定の数の関数をコンパイル後、JIT コンパイルを無効にするデバッグオプション。 このオプションは、JITコンパイルが失敗している原因を二分探索するのに役立ちます。 注意: このオプションは、「JITを行うトリガ」が 0 (スクリプトの読み込み時に全ての関数をコンパイル) または 1 (最初の実行時に関数をコンパイルする) の場合に機能します。たとえば opcache.jit=1215 の場合です。opcache.jit も参照ください。

opcache.jit_prof_threshold float

JITを行うトリガに "最初のリクエスト時にプロファイリングを行う" モードが指定されている場合、 どの関数がホットであるかはこのしきい値によって決まります。 特定の関数の呼び出し回数を、全関数の呼び出し回数で割った数は、この値以上でなければなりません。 たとえば、0.005 という値を指定すると、 全ての呼び出しの 0.5% 以上を占める関数が JITコンパイルされるという意味になります。

opcache.jit_max_root_traces int

ルートトレースの数の最大値を指定します。 ルートトレースとは、最初に実行されるコードの実行フローのことで、 これが JIT のコンパイル単位になります。 この最大値に達すると、JIT は新しくコードをコンパイルしません。

opcache.jit_max_side_traces int

ルートトレースが、サイドトレースを最大いくつ持つことができるかを指定します。 サイドトレースとは、コンパイル済みのルートトレースのパスとは別の実行フローのことです。 同じルートトレースに属するサイドトレースは、 この最大値に達するとコンパイルされません。

opcache.jit_max_exit_counters int

サイドトレースの出口のカウンタを最大いくつ持つかを指定します。 この数によって、全ルートトレースが持つサイドトレースの数の合計値を制御できます。

opcache.jit_hot_loop int

何回イテレーションが行われたら、そのループをホットと判断するかを指定します。 有効な値の範囲は [0,255] です。 範囲外の値 (例: -1256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどのイテレーションにおいてもコンパイルとトレースをしなくなります。

opcache.jit_hot_func int

何回関数呼び出しが行われたら、関数をホットと判断するかを指定します。 有効な値の範囲は [0,255] です。 範囲外の値 (例: -1256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどの関数呼び出しにおいてもコンパイルとトレースをしなくなります。

opcache.jit_hot_return int

何回リターンした場合に、そのリターンをホットと判断するかを指定します。 有効な値の範囲は [0,255] です。 範囲外の値 (例: -1256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどのリターンにおいてもコンパイルとトレースをしなくなります。

opcache.jit_hot_side_exit int

サイドトレースから何回抜けたら、ホットと判断するかを指定します。 有効な値の範囲は [0,255] です。 範囲外の値 -1256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどのサイドトレースから抜けてもコンパイルとトレースをしなくなります。

opcache.jit_blacklist_root_trace int

ブラックリストに入れるまでに、ルートトレースのコンパイルを最大何回試みるかを指定します。

opcache.jit_blacklist_side_trace int

ブラックリストに入れるまでに、サイドトレースのコンパイルを最大何回試みるかを指定します。

opcache.jit_max_loop_unrolls int

ルートトレースに達して外側のループが閉じられるまでに、 サイドトレース内で行えるループ展開の回数の最大値を指定します。

opcache.jit_max_recursive_calls int

再帰的な呼び出しループを展開する最大の回数を指定します。

opcache.jit_max_recursive_returns int

再帰的に行われるリターンを展開する最大回数を指定します。

opcache.jit_max_polymorphic_calls int

(動的な、もしくはメソッドの)ポリモーフィックな呼び出しのインライン化を試みる回数の最大値を指定します。 この呼び出し回数を超えると、メガモーフィックと見なされ、インライン化されません。

add a note

User Contributed Notes 7 notes

up
20
damien at overeem dot org
7 years ago
When using PHP on a windows platform and enabling opcache, you might run into occasional 500 errors. These will appear to show up entirely random.

When this happens, your windows Event log (Windows Logs/Application) will show (probably multiple) entries from Zend OPcache with Event ID 487. Further information will state the following error message: "Base address marks unusable memory region".

This issue can be resolved by adding the following to your php.ini:

opcache.mmap_base = 0x20000000

Unfortunately I do not know the significance of the value "0x20000000". I can only tell you that this value works to solve the problem (Tried and tested)
up
8
carneiro at isharelife dot com dot br
4 years ago
If you try to allocate more memory that is available using opcache.memory_consumption PHP stops working without any logs to help on debugging. This issue took me 4 hours to solve when creating a staging server with same configrations and less memory that was available on production server.
up
9
wessos at example dot org
6 years ago
The optimization levels as of php 7.3 are the following:

#define ZEND_OPTIMIZER_PASS_1 (1<<0) /* CSE, STRING construction */
#define ZEND_OPTIMIZER_PASS_2 (1<<1) /* Constant conversion and jumps */
#define ZEND_OPTIMIZER_PASS_3 (1<<2) /* ++, +=, series of jumps */
#define ZEND_OPTIMIZER_PASS_4 (1<<3) /* INIT_FCALL_BY_NAME -> DO_FCALL */
#define ZEND_OPTIMIZER_PASS_5 (1<<4) /* CFG based optimization */
#define ZEND_OPTIMIZER_PASS_6 (1<<5) /* DFA based optimization */
#define ZEND_OPTIMIZER_PASS_7 (1<<6) /* CALL GRAPH optimization */
#define ZEND_OPTIMIZER_PASS_8 (1<<7) /* SCCP (constant propagation) */
#define ZEND_OPTIMIZER_PASS_9 (1<<8) /* TMP VAR usage */
#define ZEND_OPTIMIZER_PASS_10 (1<<9) /* NOP removal */
#define ZEND_OPTIMIZER_PASS_11 (1<<10) /* Merge equal constants */
#define ZEND_OPTIMIZER_PASS_12 (1<<11) /* Adjust used stack */
#define ZEND_OPTIMIZER_PASS_13 (1<<12) /* Remove unused variables */
#define ZEND_OPTIMIZER_PASS_14 (1<<13) /* DCE (dead code elimination) */
#define ZEND_OPTIMIZER_PASS_15 (1<<14) /* (unsafe) Collect constants */
#define ZEND_OPTIMIZER_PASS_16 (1<<15) /* Inline functions */

Source: https://lxr.room11.org/xref/php-src%40master/ext/opcache/Optimizer/zend_optimizer.h
up
6
tizian dot schmidlin at gmail dot com
5 years ago
It should be noted that according to the original RFC (https://wiki.php.net/rfc/preload) `opcache.preload` caches preloaded files *forever* for all instances of the underlying PHP process.

That means, that hosting multiple websites on the same server might result in some unexpected behaviour.

Concrete example:
- you have a Symfony 3.2 App (which might be an endpoint of some type) and a Symfony 3.4 App (which might be your main application)
- both apps have a main Class called App that is in the same namespace (as it is usual, since the class name is unique to each project)
- depending on which app is loaded first, one or the other will work, since `opcache.preload` has no file based distinction of what class is used where and simply provides them to the user space

This is avoidable by simply not preloading user space classes or, if you work with FPM, by defining a pool for each app.

In order to optimize memory consumption, you might also use a common FPM Pool for all Symfony 3.4 Apps and preload the entire framework in there and simply not preload user space classes (which might be cached by opcache anyway but is slower, since it will be checked if the file has changed on every request).
up
4
bdurand at ensemblegroup dot net
7 years ago
It would appear as though the [opcache.enable] setting is indeed NOT PHP_INI_ALL.
For changing it within user.ini yields no effect when disabled at global level. user.ini is ignored for that setting.
up
1
JReezy
7 months ago
Despite the set of values for opcache.max_accelerated_files including the value 1048793, the maximum as stated is 1000000. If you select a number above 1000000 the value is set its default which is 10000.
up
0
daniel at elementor dot com
7 months ago
When opcache.use_cwd=0 include/require of relative paths from different directories will both resolve to the same (first) file.

Example dir structure:
app1
index.php
lib.php
app2
index.php
lib.php

both index.php(s):
include "lib.php";

app1/lib.php:
echo "app1";

app2/lib.php:
echo "app2";

both will echo "app1".
To Top