共有ホスティングを使用していますが、APCを有効にできません。それについてのスレッドがありました ここ 、そして提案された唯一の理由はセキュリティのためでした(php-cgi対mod_php)。ホストに問い合わせたところ、パフォーマンス上の理由、特にI/Oによってボックスがダウンすることが原因であるとのことでした。私はそれを本当に理解していません-確かに共有メモリオペコードキャッシュを使用すると、少ないI/Oがありますか?基本的に、共有ホスティング会社を設立する場合(私はできませんでした!)、すべてのクライアントのパフォーマンスを向上させるためにキャッシュを使用することは(セキュリティが許可されている場合)非常に理にかなっていると思いました。
誰かが私のためにこれにいくつかの光を当てることができますか? TIA
共有ホスティングプランでのAPCは一般的に良い考えではないと思います。
あなたのホスティングの答えは正しいですが、それだけが理由ではありません。
共有ホスティングを取得するときは、サイトがホストされているサーバーを使用しているのはあなただけではないことに注意する必要があります。ホスティング会社のサーバーによっては、そのマシンでサイトをホストしているクライアントが300(またはそれ以上)存在する場合があります。
多くの場合、これらのサイトには多くのphpファイルがあります。たとえば、 joomla 1.6 ドリブンサイトには〜3000 php(〜10mb)ファイルがあります(サイトと管理パネルを含みます)。 300人のクライアントすべてがJoomlaプラットフォームを使用していて、サイトが
つまり、これらのクライアントはすべて、最終的にキャッシュされる〜900000ファイルを持つことになります-〜3000mb RAMはphpファイルのキャッシュにのみ使用されます。APCでご存知のように、「ユーザーキャッシュ」を保存することもできます。通常、設定またはシリアル化されたオブジェクトを保存できるエントリ」。保存する内容によって異なるため、RAMがそこにいくらになるかはわかりませんが、さらに50〜100 MBを追加するとします。
今のところ、約3,1GBのRAMを使用しています。
ここで、実行する基本サービス(Apache、FTP、PHP、MySQL、PostgreSQL、SendMail、サーバーバックアップツール)に必要なRAMを追加します。おそらく近くにあるでしょう。 5〜6GB RAMほぼ永続的に使用されます。
APCのその他の問題は、キャッシュするときに発生します。キャッシュしたものは誰でも見ることができます(私が知る限り)。したがって、保存するものを暗号化する必要があります。これには、常に暗号化/復号化するため、より多くのCPUが必要になります。また、誰かが誤ってキャッシュされたファイル/ユーザーエントリをすべてクリアした場合、サーバーは再キャッシュしようとして狂ってしまいます。
結論として、システム管理者がAPCを有効にしてサポートするために* ssのすべての苦労を経験することはありません。これも会社にとってのメリットではありません。彼らは、APCを扱ってサーバーがダウンしないのか、何かがすぐにうまくいかないのか疑問に思うよりも、300人以上のクライアントにお金を払ってもらいたいと考えています。
より良い解決策は、クライアントが(管理された)専用サーバーを取得する場合です。そうすれば、クライアントはそのサーバーでサイトをホストする唯一のクライアントになり、サーバーに必要なものをインストールするようにサポートに依頼できます。これははるかに簡単になり、clietn、システム管理者、およびホスティング会社が白髪になるのを防ぐことができます:)
これが、APCが共有ホスティングに含まれていない理由をもう少しよく理解するのに役立つことを願っています。
あたり: http://www.php.net/manual/en/apc.configuration.php#ini.apc.mmap-file-mask
apc.mmap_file_mask文字列
-enable-mmapを使用してMMAPサポートを使用してコンパイルした場合、これは、決定のためにmmapモジュールに渡すmktempスタイルのfile_maskです。 mmapされたメモリ領域がファイルでバックアップされるのか、共有メモリでバックアップされるのか。ストレートファイルバックmmapの場合は、/ tmp/apc.XXXXXX(正確に6[〜 #〜] x [〜#〜]s)。 POSIXスタイルのshm_open/mmapを使用するには、マスクのどこかに。shmを配置します。例えば/ apc.shm.XXXXXX/ dev/zeroに設定することもできます-)カーネルの/ dev/zeroインターフェイスを匿名のmmapメモリに使用します。未定義のままにすると、匿名のmmapが強制されます。
バックアップされたファイルを使用する場合、サーバーに着信するトラフィックの量に応じて、IO)が確実に増加します。
これにより、すべてのPHPファイルをメモリにロードしておくのに十分なメモリがない限り、共有ホストのパフォーマンスが低下します。一般的にヒットしない可能性のあるファイルをキャッシュしようとするユーザーが多数いる場合は、サーバーはスワッピングを開始します。これにより、そのマシン上のすべてのパフォーマンスが低下します。
https://stackoverflow.com/questions/1053810/php-apc-what-happen-when-apc-cache-is-full によると、メモリがいっぱいになるとキャッシュがフラッシュされます。 ttlは0です。ゼロに設定されていない場合、LRU(最近使用されていない)メカニズムを使用します。
APCを使用することは常に有益であるように私には思えます。
@tftdは、共有ホスティングでAPC、Memcachedなどを有効にしない主な理由を述べました。ただし、共有サーバーが実際には共有されておらず、自分のプロジェクト(または、Webデザイン/開発の顧客で、FTP /パネルアクセスを許可していない場合)でのみ使用されている場合、そのサーバーはAPC /の恩恵を受けることができます。 Memcached/etc。
いずれにせよ、I/Oの問題は、APCが利用できるRAMに依存していると思います。利用可能なRAMが少ない場合、または利用可能な場合、一部のエントリを無効にし、新しいエントリをキャッシュしようとするためです。サイト/ PHPファイルの数が非常に多い(共有ホスティングの一般的なケース)。 RAMが十分にあり、apc.php(APCの情報ページ)を監視している場合、これは問題にはなりません。
それに加えて、APCの利点は、めったにアクセスされないPHPファイルのキャッシュはそれほど重要ではないため、中程度/高トラフィックのサイトで最もよく感じられます。