php.ini の設定により動作が変化します。
どこで設定を行うのか を参照してください。以下に設定ディレクティブに関する 簡単な説明を示します。
opcache.enable
bool オペコード・キャッシュを有効にします。 無効にした場合、コードは最適化もキャッシュもされません。 opcache.enable
の設定を、実行時に ini_set() で有効化することはできません。 実行時にできるのは、無効化だけです。スクリプト内で有効化しようとすると、警告が発生します。
opcache.enable_cli
boolPHP の 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_protection や opcache.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
stringOPcache ブラックリスト・ファイルの場所。 ブラックリスト・ファイルは、高速化すべきではないファイルの名前を 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
stringOPcache が使用する優先のメモリ・モデル。 空のままにすると、OPcache は最も適切なモデルを選びます。 それは実質的にすべての場合に正しい振る舞いです。
可能な値には、mmap
、shm
、 posix
および win32
があります。
opcache.protect_memory
boolスクリプト実行中に予期しない書込みから共有メモリを保護する。 これは、内部のデバッギングだけに役立ちます。
opcache.mmap_base
stringWindows 上で共有メモリ・セグメントに使用される基底。 すべての PHP 処理は、共有メモリを同じアドレス空間にマップしなければいけません。 このディレクティブを使用すると、"Unable to reattach to base address" (基底アドレスに再アタッチできません) というエラーを修復できます。
opcache.restrict_api
stringOPcache API 関数の呼び出しを、指定した文字列から始まるパス上の PHP スクリプトからだけに制限します。 デフォルトは "" で、これは、何も制限しないことを意味します。
opcache.file_update_protection
stringここで指定された秒数の間は、キャッシュすることを防ぎます。 これにより、不完全に更新されたファイルがキャッシュされることを防止します。 全てのファイルの更新がアトミックに行われる場合、 この設定を "0" に設定することで、パフォーマンスを向上させられる可能性があります。なぜなら、こうすることでファイルがすぐにキャッシュされるからです。
opcache.huge_code_pages
boolPHPコード(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
boolchroot された環境での名前の衝突を防止します。 これは、chroot 以外でのファイルへのアクセスを防止するために、 chroot されたすべての環境で有効にする必要があります。
opcache.preload
stringサーバーが起動した際にコンパイルされ、実行されるPHPスクリプトを指定します。 ここで指定したファイルは include されたり、opcache_compile_file() 関数で指定されることで他のファイルも事前ロードするかもしれません。 それらのファイルに指定された全てのエンティティ(e.g 関数やクラス) は、サーバーがシャットダウンされるまで、外部からのリクエストに対して利用できるようになります。
注意:
コードの事前ロードは、Windows ではサポートされていません。
opcache.preload_user
string 指定されたシステムユーザでコードを事前ロードするようにします。 これは、特権がないシステムユーザに切り替える前に、 root で起動するサーバーの場合に役立ちます。 root ユーザでコードを事前ロードすることは、 セキュリティ上の理由からデフォルトでは禁止されています。 但し、このディレクティブに明示的に root
を指定した場合は許可されます。
opcache.cache_id
stringWindows では、同じユーザーアカウントで同じ PHPSAPI を実行し、 かつ同じ cache ID を持つ全てのプロセスが同一の OPcache インスタンスを共有します。 cache ID の値は自由に選べます。
IIS の場合、異なるアプリケーションプールは 環境変数 APP_POOL_ID を opcache.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
floatJITを行うトリガに "最初のリクエスト時にプロファイリングを行う" モードが指定されている場合、 どの関数がホットであるかはこのしきい値によって決まります。 特定の関数の呼び出し回数を、全関数の呼び出し回数で割った数は、この値以上でなければなりません。 たとえば、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]
です。 範囲外の値 (例: -1 や 256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどのイテレーションにおいてもコンパイルとトレースをしなくなります。
opcache.jit_hot_func
int 何回関数呼び出しが行われたら、関数をホットと判断するかを指定します。 有効な値の範囲は [0,255]
です。 範囲外の値 (例: -1 や 256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどの関数呼び出しにおいてもコンパイルとトレースをしなくなります。
opcache.jit_hot_return
int 何回リターンした場合に、そのリターンをホットと判断するかを指定します。 有効な値の範囲は [0,255]
です。 範囲外の値 (例: -1 や 256) を設定すると、 デフォルトの値が使われます。特に 0 を設定すると、 JIT はどのリターンにおいてもコンパイルとトレースをしなくなります。
opcache.jit_hot_side_exit
int サイドトレースから何回抜けたら、ホットと判断するかを指定します。 有効な値の範囲は [0,255]
です。 範囲外の値 (例: -1 や 256) を設定すると、 デフォルトの値が使われます。特に 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(動的な、もしくはメソッドの)ポリモーフィックな呼び出しのインライン化を試みる回数の最大値を指定します。 この呼び出し回数を超えると、メガモーフィックと見なされ、インライン化されません。