2009-08-04 11 views
6

PHPでのキャッシュについてのこれまでの回答と、リンク先の記事を読んだことがあります。私は、お勧めのPear Cache_Light、QuickCache、およびWordPress Super Cacheをチェックしました。 (申し訳ありません - 明らかに私はハイパーリンクを1回だけ許可されています)並行処理を処理するPHPのページキャッシュ?

並行処理の問題を扱っていないか、文書に明示的に記載していないものがあります。

誰でも私が並列性を扱うPHPページキャッシュの方向を指すことはできますか?

これは共有ホスト上にあるため、memcacheとopcodeのキャッシュは残念なことにオプションではありません。私はテンプレートエンジンを使用せず、1つに依存することを避けたいと考えています。 WPスーパーキャッシュのアプローチが好ましい。つまり、Apacheに要求を出すためにwwwrootの下に静的ファイルを格納する。

ありがとうございます!

P.S.自動的に処理されるべき事例:

  1. Apache/PHPキャッシュは、キャッシュされたファイルを読み込む途中です。キャッシュされたファイルは廃止され、削除が試行されます。
  2. キャッシュされたファイルは廃止されたため削除されました。そのファイルの要求が入ってきて、そのファイルは再作成中です。 この中に別のファイルが入ってきます。

答えて

0
  1. は、Linuxの下では、一般的に、ファイルは、プロセスがファイルを閉じるまで、それが「削除」だ場合でも、読み取りのための「開いた」ままになります。これはシステムに内蔵されているもので、時にはディスク使用量のサイズに大きな差異が生じることがあります(まだ開いている間に3Gファイルを削除すると、プロセスが終了するまで使用中のままディスクに割り当てられます) Linuxで同じものが正しいかどうかは不明です。
  2. ジャーナリングファイルシステム(ほとんどのLinuxファイルシステムとNTFS)を仮定すると、プロセスがファイルを閉じるまで、ファイルは「作成済み」と見なされるべきではありません。これは、存在しないファイルとして表示されるはずです!
  3. ジャーナリングファイルシステム(ほとんどのLinuxファイルシステム、およびNTFS)を想定すると
+0

編集のおかげで、これは有益です。 「何が起こるの?」 P.S.の質問単に修辞的であった。私はこれを反映するために質問を更新しました。 – WalterGR

+0

Ack!私は質問のタイトルに "Implementing/finding"を書いたことを忘れていました。私は「実装する」を削除しました。それについては、私は別の質問を開きます。再度、感謝します。 – WalterGR

0

- は、そのファイルには、ファイルを閉じ プロセスまで、「作成」として見るべきではありません。これは、存在しないファイルとして表示されます。

いいえ、作成するとすぐに表示され、ロックする必要があります。 しかし、名前は原子です。したがって、open()、write()、close()、rename()を実行できますが、同じキャッシュ項目が同時に2回再作成されることはありません。

キャッシュされたファイルは廃止されたため削除されました。 そのファイルの要求が受信され、そのファイルは再作成中です。この間、ファイルの別の要求が出されます。

ロックされていない場合は、半完成ファイルが提供されるか、2つのプロセスが同じファイルを同時に再生して「面白い」結果を得ようとします。

2

PEAR :: Cache_Liteには並行性の問題を処理するためのセキュリティがあるようです。
あなたがconstructor Cache_Lite::Cache_Liteのマニュアルを見てみる場合は、それらのオプションがあります。

fileLocking /無効fileLockingを有効にします。 状況下でキャッシュの破損を避けることができます。

writeControl 書き込み制御を有効/無効にします。書き込み制御を有効にすると、キャッシュの書き込みは遅くなりますが、 キャッシュは読み取られません。 読み取り。書き込み制御では、一部の キャッシュファイルが破損していることが検出される可能性がありますが、 は完全な制御ではありません。

readControl 読み出し制御を有効/無効にします。有効にした場合、コントロールキーは キャッシュファイルに埋め込まれ、このキーは、読み取り制御の 読ん

readControlType タイプ(読み込み制御が有効な場合のみ)して計算して1と を比較しました。 'crc32'(crc32ハッシュ コントロール(軽く安全ではありませんが、 速い))または 'strlen'(長さが の場合のみ、「md5」である必要があります)、 (最も速い))

あなたが犠牲にすることができるパフォーマンスの種類とアプリケーションにおそらく存在する同時アクセスの危険性に依存します。


また、バックエンドとしてZend_Cache_Backend_Fileのようなものを使用して、ページをキャッシュするために、Zend_Cache_Frontend_Outputを見てみたいことがあります。

1は、同様に、セキュリティのいくつかの種類をサポートしているようだ

- としてCache_Liteはすでにあなたにを与えたものと同じkinfを(私はコピー&ペーストではないだろう第二回)


sidenote、あなたのウェブサイトが共有ホスト上で動作する場合、の多くのユーザーがを持っていないと思いますか?それで、同時アクセスのリスクはおそらくそれほど高くないでしょうか?

とにかく、私はおそらく、それらの牽引フレームワークを提案しているものを任意の遠くそれを検索しません:それはすでに

:-)アプリケーションのニーズには十分おそらく多くである(私は任意のキャッシュmecanismを見たことがありません「より安全な」ものは、​​あなたが行うことができ何よりも...と私はまだその種のいくつかの致命的な同時実行性の問題に遭遇したことがありません... PHP開発の3年間で)

とにかく


:持っています楽しい!

+0

Pear Cache_Lightは、ファイルが書き込み用にロックされているときにキャッシュから読み取るなど、すべての並行処理の問題を処理しません。 (または、おそらく私は言うべきです:同時実行性の問題はアプリケーションコードにパントされています)。あなたは尋ねました、 "...同時アクセスの危険性はそれほど高くないでしょうか?"訪問者は明らかに大きなトレンドに従います(例えば、深夜、水曜日など)。秒単位のページリクエストはランダムです。同時実行性はすべてのWebサイトで問題になります。 – WalterGR

0

データベースにページをキャッシュすることができます。単純な「名前、値」テーブルを作成し、キャッシュされたページを格納するだけです。

+0

ありがとうございます。データベースでは、ファイルで可能な破損の問題を回避することができますが(ACIDの "C"のため)、他の処理が適切に行われます。 ACIDの "I"。 「単にDBテーブルを作成する」という問題ではありません。 – WalterGR

1

既存のキャッシュの1つを変更したいと思うでしょう。Zend Frameworkのキャッシュはそのトリックを行うことができるはずです。もしそうでなければ、私はそれを変更するでしょう。

本当に基本的なロック戦略を作成できます。データベースを使用してキャッシュされたアイテムをすべて追跡し、更新のロックを許可し、他の人の更新が完了するのを待つことができます。

これはACIDの問題を処理します。あなたは他の誰かのアップデートのロックを非常に短期間に設定することもできますし、サーバーの負荷と容量とキャッシュされたコンテンツを作成するコストに応じて、ラウンドトリップのためにキャッシュ全体をスキップすることもできます。キャッシュスラミング/スレッドレース別名

ヤコブ

1

同時リソースの作成が忙しいのウェブサイト上の深刻な問題になることができます。そのため、私は読み取り/書き込みプロセス/スレッドを同期させるキャッシュライブラリを作成しました。

これは、エレガントで明確な構造を持っています。インタフェース - >アダプター - >クラスを簡単に拡張できます。 githubのページで、スラミングの問題とライブラリの解決方法を詳しく説明しています。

ここでそれを確認してください: https://github.com/tztztztz/php-no-slam-cache