回答:
SVNプッシュ環境で実行するため、スクリプトを使用してapcファイルキャッシュのみをクリアします。
APC設定：
apc.ttl=604800
apc.user_ttl=3600
apc.shm_size=192M
apc.include_once_override=1
auto_globals_jit=Off
apc.num_files_hint = 2048
apc.stat_ctime = 0
apc.file_update_protection = 2
apc.stat = 0PHPスクリプト：
<?php
$return = apc_clear_cache('opcode');
echo var_export($return);604800 = 1週間。
この後、xdebug / xhprofを起動して実行し、サイトのキャッシュグラインドを実行すると、サイトの速度が低下していることがわかります。要するに、キャッシュのグラインド出力を分析することが、Drupalを高速化する最良の方法です。以下に、高速化に使用するパッチとモジュールをリストします。あなたの場合、それはおそらく異なるでしょう。
以下のDrupal 6固有の回答
このポイントを過ぎて、APCが探しているものを提供してくれないことに気付いたら、プレスフローに切り替えて、これらのパッチを試してみてください。
また、これらのモジュールをいくつか試してみてください。サイトの速度が大幅に向上したためです。
これは、「文字列の質問の長さ」の1つです。
大量のサイトに適しているのは、多数のモジュールを備えた少量のサイトとは異なる場合があり、少数のモジュールのみが有効になっている中規模のサイトでは同じではない場合があります。サーバーで実行されている他のサイトも、APCが使用可能なメモリを食い尽くしている可能性があります。
私の出発点は
apc.enabled=1
apc.shm_segments=1
apc.shm_size=64
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1
apc.rfc1867=1次に、サーバーの設定を調整しますが、すべての設定に適合するサイズはありません。
apc.php（おそらく/usr/share/pear/apc.phpにあります）を見つけ、Drupalのインストール用にDOCROOTにインストールします。Apache configを介してIPアドレスにロックダウンします。内部のユーザー名/パスワードを編集し、参照します。その後、APC統計が表示されます。
キャッシュミスを最小限に抑えるためにshm_sizeパラメーターを再構成します。理想的には、ファイルのキャッシュミスが発生しないように十分なメモリと、APCユーザーキャッシュ用の追加メモリを提供する必要があります。
TTLを最適化して、キャッシュチャーニングを防止します。ファイルを編集していない場合は、この数を増やすことができます。
enable_cliは、drushを頻繁に使用するときに便利です。そのため、drushはAPCのキャッシュファイルを使用します。
rfc1867はファイルのアップロードに便利です。
また、タイトルにphp-fpmがあることに気付きました。これは問題を複雑にし、Drupal Answersの範囲を超えています。多くのシステム構成設定はDrupalに直接関係しないため、Server Faultでより良い応答を得ることができます。
APCは、PHPファイルの読み込みと解析を改善するだけです。大部分は、実行時間そのものでもあります。バグ（特にキャッシュ関連のバグ）、内部オーバーヘッド（drupal_alter（）、module_implements（））などを含む、実行時間を増やすことができる多くの要因があります。
mikeytown2から尋ねられ、すでに提案されているように、ボトルネックの場所を見つけるためにxhprofを使用します（結果への直接の迅速なアクセスを提供し、追加のツールを必要としないため、最近はxdebugよりもそれを好みます）。
最近、Drupal内でxhprofを使用することと典型的なボトルネックに関する2つのブログ記事を書きました。