memcachedを使ったPHPのシングルトン実装？
以前、以下のページを参考にコードを書かれて困ったのを思い出したので。
先にことわっておくと、このページ自体に罪はない*1ですし、
限定的な条件では利用できる*2技術だと思いますが、
ありがちな罠が幾つかあるので列挙。
排他制御
ただし今回の実装は排他制御を行っていないのでそのままでは使えませんが…。
アプリケーション全体でのデータ共有が目的なので、そのレベルのロック
処理を自分で入れて使って下さい。 使いたい人はガンバレ…
serialize
クラスのオブジェクトデータを保存する際に serialize するので、
クラスインスタンスに serialize 不可な変数が入った時点で破綻します。
object サイズ
この方式では、オブジェクトを生成/破棄する度に unserialize/serialize
& memcache との入出力処理が働きます。 つまり、インスタンス変数に巨大な
データを入れたまま放置すると危ないです。そもそも、「その」リクエスト
処理で必要ないデータまで入出力するのはどうかと…
ゴミデータ
object サイズの件と絡みますが、データが要らなくなった場合に明示的に破棄
しないとダメで、それをアプリケーション全体レベルで考える必要があります。
クラスの改造
クラスファイルを update すると、memcache 上のイメージと合わなくなるかも
しれません。停止メンテナンスですか、そうですか。
slashdotやmixiも使っている？
...から大丈夫でしょ。という事を言われたのですが、
パフォーマンスは悪くないのでオブジェクトに限らず画像やテキストなど キャッシュさせれば負荷を軽減させるのに役立つのではないでしょうか。 slashdotやmixiも使っているようですし。
この文章の前には、 MySQL やファイルI/O との比較が載ってますし、
「...に限らず...画像やテキストなど...ようですし」という流れなので、
「slashdot や mixi も memcached を使っているようですし」であって、
PHP クラスのインスタンスとして使っているとは言ってないはず。
そもそも mixi が Perl で動いてるのは有名な話ですし。
最後に…
斜め読み(で終わらす人)って怖いね… (´Д｀;)
自分も結構誤読する事があるので気をつけよう。ひとのふり見て我がふり直せ…
