3

私がそれらの設定を理解している限り：

opcache.validate_timestamps=0
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=3907
opcache.blacklist_filename=/blacklisted_files

パフォーマンスが向上するはずです（リンクによると：1、2および3）。最後の2については実際にはわかりません。私の場合、「internet_strings_buffer」の設定値「4」は決して満たされない可能性があります（したがって、より良い結果が得られません）が、「validate_timestamps」は stat() 関数のオーバーヘッドを削除する必要があるため、より良い結果が得られますパフォーマンスですが、JMeter でのテストによると、それを検証できません。各設定は個別にデフォルト設定よりも悪いです。

「パフォーマンス設定」があまり改善されない可能性があることは理解していますが、パフォーマンスが低下するべきではないと思います (差はリクエストごとに約 +2 ミリ秒です)。

質問:デフォルト設定がパフォーマンス/推奨設定よりも優れているのはなぜですか?

また、OPcache は小さなメモリの上書き/削除/検索を大きなメモリよりもうまく処理しますか (「opcache.memory_consumption」設定について話します)?

4

1 に答える 1

4

オプション 2 と 3 は、オペコード キャッシュの容量に関連するという点で、パフォーマンスに間接的にのみ影響します。現在の使用量がデフォルトの範囲内に収まっている場合、Opcache を使用することによるシステム オーバーヘッドのわずかな増加以外に、実質的な違いは見られません。もちろん、現在の使用量が収まらない場合は、キャッシュの容量が大きくなり、キャッシュ ミスが少なくなるため、メリットが得られます。

オプション 4 は、揮発性であるためキャッシュしてはならない PHP スクリプト ファイル名のパターンの定義に関連しています。このような変更は Opcache によって取得されないため、タイムスタンプの検証を無効にしている場合、これは特に重要です。

straceオプション 1 は、PHP プロセスの 1 つが検証できる余分な stat() 呼び出しを削除します。最近の CPU では、Linux カーネルは inode を非常に効率的にキャッシュするため、ノードが VFAT キャッシュにある場合にのみサブミリ秒しか節約できません。この違いを測定するには、タイミング テストを適切に作成する必要があります。

Opcache の再利用戦略は非常に貧弱です。気にする必要はありません。キャッシュはゆっくりといっぱいになり、いっぱいになると完全にフラッシュされ、最初から再構築されます。

于 2014-12-07T11:45:03.083 に答える